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1. Extend Rental Use Case 

1.1 Application Overview 

The following is a document used to illustrate the process for how the USER will extend a previously 
authorized rental using ARMS/Web 3.0. The intent for this release of the ARMSAVeb application is to 
reach a much wider audience. This application will target a Multi- Vendor, Multi-Segment, and 
International customer base. 

1 .2 Brief Description 

This use case will describe how the USER will extend a previously authorized rental. The rental company 
(via an Authorization Request), the RENTAL ADMINISTRATOR (via a Customer Search), or Reporting 
(via the Callback feature) can initiate this use case. 

1.3 Use Case Actors 

The following actors will interact with this use case: 

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to 
extend a previously authorized rental. This use case refers to a USER in the role of a rental 
administrator. There are various types of customers that the USER would represent, which 
include corporate account holders, car dealerships, insurance companies, and others. 

• ARMS - The ARMS system will receive/send transactions to ARMSAVeb to confirm the 
extended rental. 

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this 
system as well. Each company will have the ability to initiate and manage their rentals through 
the use of this application. 

1.4 Pre-Conditions 

• The USER must have logged into the ARMSAVeb system. 

• The USER must have selected a previously authorized, open rental. 

1.5 Flow of Events 

The Flow of Events will include the necessary steps to make changes and updates to "Extend Rental". 




Basic Flow 

The system will display the details of the Rental. 

The USER will enter the number of days to extend the rental. 

The USER will submit the Extend Rental Details. 

The system will validate the number of days the rental will be extended. 

The system will update the ARMSAVeb database with the Extend Rental Details. 

The system will read the profile for the confirmation screen setting. 

For non-Enteiprise rentals, the extension is sent to the non-ERAC renal car company's rental 
system. 

This ends the use case. 

Alternative Flows 

1. 5.3. 1 View Rental Notebook 

At step 1 of the basic flow, the USER may choose to view the history of a rental. The USER will 
be able to see the diary notes associated with the Reservation / Rental. 

1.5.3.2 Display Confirmation 

After step 7, the USER may wish to have a confirmation page displayed, indicating that some 
type of change has taken place. The confirmation page is completely optional; therefore, at 
anytime the USER wants to set their profile to bypass this screen, he/she may do so. 

1.5.3.3 Update USER Profile 

During the confirmation process, the USER has the option of changing their profile setting to 
display or hide the confirmation page. Each time the setting is changed, the USER profile must 
be updated to reflect the new requirements set by the USER. 

1.5.3.4 Validate Changes 

If the USER changes or adds information, which does not pass validation, an error message will 
notify the USER and return them to step 1 of the Basic Flow. 

If an error is discovered in the validation of the reservation / rental information submitted by the 
USER, the system would present the USER viith an error message and return them to the 
Detailed Reservation / Rental Display. If the error is specific to a data field within the form, the 
field should be highlighted and the error described. 

1. 5. 3. 5 Ctiange Customer File 

Prior to step 3, the USER has the option to make changes to the customer file. After clicking the 
change/add link, the screen will refiesh with all editable fields opened and available for the 
USER to make changes. 

1. 5.3. 6 Update ARMS/Web Database 

After successfiiUy validating the recent changes, the system must update the ARMSAVeb 
Database. The system goes through the same process as in the Basic Flow, as the database is 
updated to reflect the latest changes. 
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1.6 Post-Conditions 

• If the use case was successful then the rental has been extended and the ARMS/Web system has been 
notified. 

• If the use case was unsuccessful then the system has remained unchanged. 

1.7 Special Requirements 

• The number of days to extend a rental must be an integer greater than zero. 

• If a USER attempts to extend an insured rental beyond their limits for number of days and dollar 
amount, the system should return an error message. 

1.8 Extension Points 



1.8.1 MA-16 Reassicin USER/Office (Transfer) 

After the extend rental detail is displayed, the USER may choose to transfer the current 
office/USER. First, the USER would select to change the current office/USER. Second, the 
system would display a list of authorized offices/USERs. Third, the USER would select a new 
ofHce/USER. If additional changes are made to the customer file, the new data will also be 
passed through the transfer process. 

1-8.2 MA-08 View Car Class 

The View Car Class use case will be used to allow the USER to view details about and select a 
car class to apply to a reservation. Details will include the average number of passengers and 
luggage items that can be served by a vehicle in the specific car class. The car class selected by 
the USER should be applied to the reservation. 

1.8.3 MA-15 Terminate Rental 

After the extend rental detail is displayed, the USER may choose to terminate the rental. If 
termination is selected, the USER must enter a reason for the termination of the rental. 
Termination means the insurance company is no longer willing to pay for the rental. 

1.8.4 MA-04 Send Message 

The Send Message will be used to allow the USER to capture messages and diary notes 
associated with extending a rental. The USER can elect to either have the message sent to the 
rental company responsible for the reservation/authorization, or (Depending on the user segment 
if this option is available) to store the note in the ARMS/Web system without sending the 
message to rental company. All MESSAGES and DIARY NOTES captured must be related to a 
specific reservation/authorization. 
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Screen Design 

A definition of the screen layout(s), screen data fields, and screen fiinctions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 




aent support tor the use case flow, x 



he/she may want to change. 



Extend Ren tal Deta il 

This screen Tvill allow the USER to pick which functions that he/she may want to change. 
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ttsirfal tjuation: 



Bowie, David 
1735 N. Paulina St. 
Chicago, ILE0622 



Home: (7T3)36i-B0BA 
Work: (773)39eB200 
email:dbowie@zefer.cor 




Direct Bill %: None 
Rental Date: 03C8/2QOO 
Start Date: 03/20QOOO 



Rental Location: 

Enterprise Edgewater 
5400 N. Ashland 
Chicago. IL60BZ2 
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Policy tBn*Kr?tV500;^ 



Cunmt HsKtal Slatnr 



Bowie. David 
1735 N. Paulina St. 
ago . IL 60622 



Authorized Class; Standard 
Days/Rate: 5 days @ $21 .99/day 
Current Class: Full-Size 

ges: None 



Start Date: OSQOQOOO 



Rental Location: 

Enterprise Edgewater 
&400 N. Ashland 
Chicago. IL 60622 
773-334-5400 



Qaim Type: Theft EIco Chevrolet 

1 Insured Name: Lalumandier. Craig Chicago, IL 60621 

Ovraer's vehicle: GMC Suburban 1999 (773)334-9832 



t Loss Type: Non-Orivable 
Policy: Daily rate/ 
" iximum dollars: 30«aO 



Message, Belanger, Hugues, 2/20/00 

Note fronn Enterprise, Sarussi, Marty, 2/21/00 

Extension Request, 2/24430 




Purchase Order 
Bil Type: Then Elc'o Chevrolet ' 

Insured Name: Ulumandier. Craig Chicago, IL 60621 

Owners vehicle: GMC Suburban 1999 (773)334-9832 
Date of Loss O3/28/20QO 
Loss Type: Non-Drivable 
Policy: Daily rate/ 
Maximum dollars: 30«00 



Message. Belanger, Hugues, 2/20/Da 
Note from Enterprise, Sarussi, Marty. 2/21/QO 
Extension Request, 2C4/0Q 
Extension, 2/25«] 
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Home (773)564-6054 
Work (773)39&€20G 
Email: dbowie@zcfer.com 
Requested erriail confirmation 



QasK Standard 
e:5days@$21.99/day 
Current Class: Full-Size 
Additional Charges: None 
Rental Date: 03/2aC000 
Start Date: 03/20/2000 



Corporale Oass Ni 
Loss Type: Non-Drivable 
Policy: Daily rate/ 
Maximum dollars: 30/EOO 



Message, Belanger, Hugues.2/2D/CI0 
Note from Enterprise, Sarussi, Marty, 2/21/0O 
Extension Request, 2/24/QO 
Extension. 2/25/00 





2.1.3 Extend Rental Detail 



Additional 
Charges 


Output 


15 


Additional Charges 






Handling For: 


Output 


30 


Handling for Adjuster's 
Name 


First Name + Last 


Last Name + First Name 


Note to Self 
Only 




50 


Message 


NOTE 




Messages: 


Output 


8 


Message Creation Date 


Add Date 


N/A. 


Note to 
Enterprise: 




50 


Message Text 


NOTE 






Output 


50 




NOTE 




Claim Number: 
Purchase Order 

Corporate Class 
Number 


Output 


11 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Insurance Claim 
Number, P0#, CC# 




Days Authorized 
to Date: 


Output 


2 


Number of Days 
Authorized 


Number Of Days 
Authorized 


N/A. 


additional 

authorized days 


Output 


2 


Number of Days to 
Extend 


Number of Days to 
Extend 




Policy Limits 


List Box 


5 


Policy Maximimi and 
Dollars per day 


Max $ Covered + 
Dollars Per Day 
Covered 






Output 


30 


Rental Location Branch 


Rental Location 




days @: 


List Box 


6 


Rental Location Rate 


Vehicle Rate 


N/A. 


Date of Rental 


Output 


10 


Rental Start Date 


Start Date 


N/A. 


Insured Name: 


Output 


30 


Insured's Name 


Name 






Output 


30 


Rental Location 
Address 


Address Line + 
Address Line2 


N/A. 




Output 


25 


Rental Location City 
Name 


City 


N/A. 




Output 


10 


Rental Location Postal / 
Zip Code 


Zip Code 


N/A. 




Output 


3 


Rental Location State / 
Province Code 


State 


N/A. 




Output 


13 


Rental Location 
Telephone Number 


Telephone Number 


N/A 


Date of Loss: 


Output 


10 


Date of Loss 


Date Of Loss 






Output 


20 


Renter City Name 


City 






Output 


10 


Renter Postal /Zip 
Code 


Zip Code 






Output 


3 


Renter State / Province 
Code 


State 






Output 


30 


Renter Street Address 


Address Line 




Home: 


Output 


16 


Rental's Home Phone 


Renters Night Phone 
+ Renters Night 
Phone Extensin 


Not editable if ticket is Open. 


















Output 


30 


Renter's Name 


First Name + Last 
Name 


Will not be editable if ticket is open. 
First Name + Last Name 


Renter 
Information: 


Output 


30 


Renter's Name 


First Name + Last 
Name 


N/A. 


Work Phone: 
— — — — — 


Output 

— 


16 


Renter's Work Phone 


Day Phone + Renters 
Day Phone Extension 


Will not be able to edit if ticket is 
Open. 


Owners vehicle: 


Output 




Vehicle Year, Make 


Renter Make/Model 
+ Renter Vehicle 




Repair Facility: 


Output 


20 


Body Shop Name 


Repair Facility Name 






Input 




Numb« 


Telephone Number 






Output 


15 


Repair Facility City 


City 






Output 




Repair Facility State 








Output 


7 


Repair Facility zip code 


Zip Code 




Last Day 
authorized 


Output 




Date rental is 
authorized through 


CALCULATED 


Calculated field. Populated with an 
Open Ticket only. 


Charges to Date: 


Output 


10 


Total Charges 


CALCULATED 




Renter Type 


Output 


10 


Claim type 


claim type 
description 




Claims Office: 


Output 


3 


Office Id 


external organization 
abbreviated name 


N/A. 


Vehicle 
Condition 


Output 


15 


Type of Loss 


loss type description 




Renter Email: 


Output 


20 


Renter's Email 


renter email 


Will not be able to edit if ticket is 
Open. 



2. 1.4 Screen Function Definition 

This section includes the definitions for all fiinctions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.4.1 S/f/p 

When clicked, the USER will be taken out of the use case without changing the current 
status of the request. Any changes made by clicking Change or Add and keying data in 
the bottom section will be saved. 

2.1.4.2 Process 

When clicked, the system will validate the input and accept the changes made to the 
customer file. The ARMSAVeb database will be updated. The use case will then end 
and the USER will return to the process from which they came. 

2.1.4.3 Notebook 

When clicked, the USER will be taken to the Note Book section at the bottom of the 
screen to view all messages for this rental. 

2.1.4.4 Set Last Date 



When clicked, the system will terminate the rental. The USER will be prompted to enter 




/I 




a termination date for this rental. This coincides Avith the use case MA- 1 7-Terminate 
Rental. 

2AA.5 Transfer File 

When clicked, the USER will be taken to the Transfer File screen. This screen allows 
the USER to change the oflSce or adjuster currently assigned to the customer file. The 
required information in the Extend Rental/Customer File mil be passed to the Transfer 
File screen. Upon completion of the transfer, the USER will then be returned to the next 
action item or the profiled start page, depending on the screen fi^om which the USER 
began. 

2.1.4.6 Change or Add 

When clicked, the system will refi^sh the current screen and make all editable fields in 
the bottom section (outside the gray box area) input capable. The changes on the top of 
the screen will not be lost. 

2.1.4.7 Top of page 

When clicked, the USER will be taken to the top of the current page. 

2.1.4.8 View Car Class 

When clicked, the USER will be taken to the View Car Class Use Case. No changes 
will be lost. Once the USER is finished with this use case, the USER will return to the 
Extend Rental Use Case. 

2.1.4.9 Extend Rental 

When clicked, the system will validate the input and accept the extension AND the 
changes made to the customer file. The ARMS/Web database will be updated. The use 
case will then end and the USER will return to the process from which they came. 
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Review List - Action Items 

1. Review List Action Items Use Case 

1.1 Application Overview 

The following is a document used to illustrate the process for how the USER would view and/or select any 
outstanding action items assigned to them using ARMSAVeb 3.0. The intent for this release of the 
ARMSAVeb application is to reach a much wider audience. This application will target a Multi-Vendor, 
Multi-Segment, and International customer base. 

1.2 Brief Description 

This use case describes how the USER would view and/or select any outstanding action items assigned to 
them. 

1.3 Use Case Actors 

The following actors will interact with this use case. 

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to 
review outstanding action items to be completed. This use case refers to a USER in the role of a 
USER. There are various types of customers that the USER would represent, which include 
corporate account holders, car dealerships, insurance companies, and others. 

• ARMS - The ARMS system will receive/send transactions to ARMSAVeb based on actions of the 
USER, retrieving and acting action items. 

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this 
system as well. Each company will have the abiUty to initiate and manage their rentals through 
the use of this application. 

1 .4 Pre-Conditions 

• The USER must be logged into the ARMSAVeb system. 

• The USER must have selected to Review a List of Action Items. 

• The system must retrieve and confirm the USER ID and access authority. 



1.5 Flow of Events 

The Flow of Events will include the necessary steps for an USER to review and assign outstanding action 
items. 





1.5.2 Basic Flow 



1 . The USER selects to review the outstanding action items list. 

2. The system retrieves the list of outstanding action items associated with the USER ID. 

3 . The system sorts and builds the hst based on the appropriate USER profile. 

4. The system will display a list of all outstanding action items assigned to the USER, which could 
include: 

• Authorize a Request 

• Extend a Rental 

• Handle Unapproved Invoices/Pay Approved Invoices 

• Send a Message 

5 . The USER will select an item from the action items list. 

6. The system displays the detail appropriate to the action item status. 

7. Upon completion of the selected action item, the system will determine the next action item and 
display until the current list has been completed. 

8. This ends the use case. 

1.5.3 Alternative Flows 

1. 5. 3. 1 Handle For A Different USER 

Until step 5, the USER may choose to handle requests for another USER At this time, the USER 
must select the appropriate USER to handle for. The system will then validate the ID of the 
alternate USER, and then rebuild the action item list to include all outstanding items associated 
with the new ID. 

1. 5. 3. 2 Re-sort Action Items List 

After displaying the action item list using the default from the profile, the USER may decide to 
sort the list based on some other criteria. At any time, the USER may choose to re-sort the action 
item list (Depending on the USER segment) based on Item Type, Date Received, Renter's Name, 
Claim Number or Corporate Class Number or Purchase Order Number, Rental Company, and 
Administrator. 

1.5.3.3 No Items Found 

If there are no Action Items available for the USER work on, the system will display a message 
indicating that there are no available action items to display. 

1.6 Post-Conditions 

None 

1.7 Special Requirements 

1.7.1 Sort Request 

The default sort order has been specified by the USERs profile, which governs the order in which action 
items have been presented. If invoices have been added to the USER'S payment list, a link displays for 
them to proceed to the 'Payment List'. Alternatively, after the last invoice has been approved, the system 
automatically proceeds to the 'Payment List' before resuming the outstanding action items. If the USER 
has been designated with the responsibility of handling the 'Unassigned Requests,' a fink at the bottom of 
the action item list displays. 





1.8 Extension Points 

An extension point indicates a link between this use case and another use case. Extension points 
associated with the use case are indicated below. Clicking on the extension point will open the related use 
case. 



1. 8. 1 MA-12-Extend Rental 

At step 5, the USER must select an action item to perfom. At this point, the USER may elect to extend a 
previously authorized rental. Extensions may be performed due to prolonged body shop delays and other 
scenarios. Upon completion of the Extend Rental process, the USER should be returned to step 5 of the 
Basic Flow. The action item that called for the extension should no longer appear in the USER'S action 
item list. 

1.8.2 MA-10- Authorize Request 

At step 5, the USER must select an action item to perform. At this point, the USER may elect to authorize 
a direct bill request. Upon completion of the authorization, the USER should be returned back to step 5 of 
the Basic Flow. The request needing authorization should no longer appear in the USER'S action item 
list. 

1.8.3 Invoicing- BI-01 -Handle Unapproved Invoices & BI-02-Pay Approved Invoices & BI-03 
Reject an Invoice 

At step 5, the USER must select an action item to perform. At this point the USER may elect to pay 
approved invoices, handle unapproved invoices, or reject an invoice. Upon completion of this process, the 
USER should be returned back to step 5 of the Basic Flow. The invoices that were processed should no 
longer appear in the USER's action item list. 

1. 8. 4 MA- 19- View Customer File (Message) 

At step 5, the USER must select an action item to perform. At this point, the USER may elect to view a 
message from the rental company. Upon completion of the message, the USER should be returned back to 
step 5 of the Basic Flow. The message should no longer appear in the USER's action item list. 




ARMS Reddsign>r^ect - Releasfe 3.0 
Revie\)Kj.isjl/- Action lfen}s / 



y^Nssue: Jl.l\ 
/ Issti^ Date: l6/20/00 ^ 





Screen Design v 

A definition of the screen layout(s), screen data fields, and screen fimctions that are used to implement the 
flows identified above. More than one screen may be used to-miplement support for the use case flow. 



; than one screen may be used tcwmpli 



2.1 Action Items (s>^^ 

This screen^^STdlow the USER to pick which fimctions that he/she may want to change. 

2J^l,^_Screen Layout - Action Items — (t^U nu9 fc .H ( ~ C'^'-^ 

(ARMSAVeb 2.0) — 






Office: j oOl 



andling for: j Yourself |2 



Action Items: welcome back, Fitrgerald. Neil. 

® 8*:ii« tlnrf ihe iiclio:^ itetrs that 



05 01-00 
05 01 00 
Ob 15 00 



lio«r».J_'.iQl 234587871 
Webiir^Aridrev 754509677 



HLERent-ACar Fitzgerald, Neil 

Enterprise Rent-ACar Fitzgerald, Neil 
Car Temps Fitzgerald, Neil 




Handling for jVourself 



Action Items: welcome back. FitzgeraW, NeU. 
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Extension 


06 01 no 


Invoice 


05-01-00 


Ratwntd hwoiee 




Payment List 


06-15-00 







It "DATE RECEIVED-) 



234587871 
VVeb.'-.- V idrcw 7545R98/7 



HLERent-ACar Fitzgerald, Neil 

Biterpnse Rent-ACar Fitzgerald, Neil 
Car Temps Fitzgerald, Neil 




2.1.2 Action Items - Summary 















Date Received 


Output 


0 


Date Received 


action item assigned 


N/A. 


Type 


Output 


15 


Action Item Type 


action item type 
description 


N/A. 


USER 


Output 


0 


USER'S Name 


First Name + Last 


N/A 


Handling For: 


List Box 


30 


Handling for USER'S 
Name 


First Name + last 


N/A. 


Welcome Back 


Output 


30 


User's Name 


Last Name + First 
Name 


N/A 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Output 


0 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Insurance Claim 
Number, P0#, CC# 


N/A. 


Renter's Name 


Output 


30 


Renter's Name 


First Name + Last 


N/A. 


Claims Office: 


List Box 


3 


Office 


external organization 
abbreviated name 





2. 1.3 Screen Function Definition 

This section includes the definitions for all functions that can be perfonned within the screen. This 
includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity. 

2.1.3.1 Renter's Name 

When clicked on a specific hyperlink under the "Renter's Name" heading, the USER will go into 
the details of that particular action item and will begin any of the following use cases: 

• MA-12-Extend Rental 

• MA-lO-Authorize Request 

• Invoicing - BI-0 1-Handle Unapproved Invoices & BI-02-Pay Approved Invoices & BI-03 
Reject an Invoice 

• MA-19-Customer File (Message) 
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Assign a Request 

1. Assign a Request Use Case 

1.1 Application Overview 

The following is a document used to illustrate the process for assigning the unassigned authorization 
requests to the appropriate user. The assignments will be made using the ARMS Web 3.0 system. The 
intent for this release of the ARMS Web apphcation is to reach a much wider audience. This application 
will target a Multi-Vendor, Multi-Segment, and International customer base. 

1.2 Brief Description 

This use case describes the process of how a USER will review unassigned authorization request and assign 
them to a USER for further handling. 

1.3 Use Case Actors 

The following actors will interact with this use case: 

• RENTAL ADMmiSTRATOR - RENTAL ADMINISTRATOR will use the system to assign the 
unassigned authorization requests. This use case refers to a USER in the role of a rental administrator. 
There are various types of customers that the rental administrator would represent, which include 
corporate account holders, car dealerships, insurance companies, and others. 

• ARMS - The ARMS system will receive/send transactions to ARMS Web to manage each phase of the 
rental process. 

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this system 
as well. Each company will have the ability to initiate and manage their rentals through the use of this 
application. 

1.4 Pre-Conditions 

• The USER must be signed-on to the ARMS Web system. 

• The USER should be authorized to assign a request. 

• If there are unassigned requests present, the USER has selected the link from the Review List Action 
Items Use Case to enter this use case. 

1.5 Flow of Events 

The Flow of Events vrill include the necessary steps to make changes and updates to "Assign an Action 
Item". 





1.5.2 Basic Flow 

1 . The USER selects the unassigned authorizations link. 

2 . The system retrieves all unassigned request summaries. 

3 . The system retrieves all OFFICE IDs within ARMS Web. 

4. The system retrieves all USER IDs within the OFFICE. 

5. The system displays the imassigned authorization summaries with the offices and users. 

6. The USER selects a user to assign to the request. 

7. The system will update the ARMS Web database. 

8. This ends the use case. 

15.3 Alternative Flows 

1.5.3. 1 Cancel Use Case 

The USER should be capable of leaving the use case at any point prior to assigning the of the 
reservation information. 

7.5.3.2 Modify a Request 

Before step 6 of the basic flow, the USER should be able to make changes to the authorization. 

1.5.3.3 Select a different office 

Before step 6 of the basic flow, the USER should be able to select a different office for this 
authorization request. If a different office has been selected, the user cannot assign the file to a 
new user. The new office must now assign the file. 

1.6 Post-Conditions 

If the use case is successM, the system will change the request type from an unassigned authorization 
request to direct bill. If the user has authority to authorize this request, the system will change the request 
to Authorized status and assign the adjuster picked in Step 5 of the basic flow. 

If the use case is unsuccessfiil, the system state will remain unchanged. 

1.7 Special Requirements 

None 

1.8 Extension Points 

1.8.1 MA-04 Send Message 

The Send Message fimction will be used to allow the user to capture messages and diary notes 
associated with a rental reservation/authorization. The USER can elect to have the message sent 
to the rental branch location responsible for the reservation/authorization. The USER may also 
send a message without assigning the file to a user/office. All MESSAGES and DIARY NOTES 
captured must be related to a specific reservation/authorization. 

1.8.2 MA-10 Authorize a Request 

The USER may decide to enter into the fiill detail screen of the unassigned request, which would 
invoke the Authorize a Request use case. 




Screen Design 

A definition of the screen layout(s), screen data fields, and screen fimctions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

Action Items -JJn assigned^ ,, [<^qj^^ ^xf ^'^ ^ ^ "^^Ij 

This screen wUl allow the USER to assign action items to an office or USER. The USER may also cancel 

an item or change specified information in the Customer File through this screen. 

2.1.1 Screen Layout - Action Items - Unassianed (ARMS Web 2.0) — Sei2jR\Oy-o5 t» 4»(0'^'^^ 




Action Items 



Oaim Numb8r^75'(589877 



Vehicle Condition:) Select a Loss Type ■«! 

Claim Type:j Select a Qoim Type^ ^ 
Date of Loss:j January 2^2000;^^:^^ 
Note to Enterpnse:j ; 



2B445 Main Ave 
Chicago, IL 60622 
555-555-1212 



shicle Condition:} Seled a Loss Type 

Claim TypB:j Select a Qaim Type * 
Date of Loss | Januajy 1 ^ 2000;jj^ 
le to Enterpnse:j \ 



junossigned 




2.1.2 Action Items - Unassianed 



Claims Office: 


Output 


3 


Office Id 


external 
organization 
abbreviated name 


N/A. 


Handling For 


Output 


30 


Handling for 
Adjuster's Name 


First Name + Last 
Name 


N/A. 




Output 


30 


Renter's Name 


First Name + Last 


This should be a link. The USER 
should be able to get to the authorize 
page from this screen field 




Output 


30 


Renter's Address 


Address Line 






Output 


10 


Renter's City 


City 






Output 


3 


Renter's State 


State 






Output 


10 


Renter's Zip Code 


Zip Code 






Output 


16 


Renter's Home Phone 


Renters Night 
Phone + Renters 
Night Phone 
Extensin 


If these fields are populated, add a 
label to the screen to differentiate 
between Home Phone and Work Phone 




Output 


16 


Renter's Work Phone 


Day Phone + 
Renters Day 
Phone Extension 


If these fields are populated, add a 
label to the screen to differentiate 
between Home Phone and Work Phone 


Claim Number 

Number 
Corporate Class 
Number 


Input 


30 


Claim Number 
Purchase Order 
Nimiber 
Corporate Class 
Number 


Insurance Claim 
Number, PC*, 
CC# 


N/A 


Vehicle 
Condition 


List Box 


15 


Loss Type 


loss type 
description 




Bill Type 


List Box 


15 


Claim Type 
Bill Type 


Rental type 
description 


N/A. 


Date of Loss: 


Input 


10 


Date of Loss 


Date Of Loss 


N/A. 


Note to 
Enterprise 




30 


Message Text 


NOTE 


N/A. 


Assign to office: 


List Box 


5 


Office Id 


external 
organization 
abbreviated name 




Assign adjuster 


List Box 


30 


Adjuster Name 


First Name + Last 
Name 


Lists only those adjusters the USER 
has authority to assign 



Screen Function Oefinition 

This section includes the definitions for all fiinctions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keysO-okes, or other actor 
activity. 

2.1.2.1 «Previous 

When clicked, the USER will be taken back to the previous screen. 

2.1.2.2 Process 

When clicked, tiie USER will be taken to the next item in the action item list or a detail of the 
completed action items. This button ends the use case 





2.1.2.3 Cancel 

When clicked, the USER will be allowed to cancel the authorization. If this occurs, the rental 
becomes unauthorized and the rental is no longer responsibility of the company. 
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View Car Class 

View Car Class Use Case 
Application Overview 

The following is a document used to illustrate the process for how the USER would view examples of 
automobiles that are part of each rental company car class using ARMSAVeb 3.0. The intent for this 
release of the ARMSAVeb application is to reach a much wider audience. This application will target a 
Multi- Vendor, Multi-Segment, and International customer base. 

Brief Description 

This use case will allow the USER to view examples of automobiles that are part of each rental company 
car class. The USER will have the ability to select a car class and have the rate for the car class apply to 
the reservation/authorization. 

Use Case Actors 

The following actors will interact with this use case: 

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to 
view and/or select the car class that will apply to a reservation. This use case refers to a USER in 
the role of a USER. There are various types of customers that the USER would represent, which 
include corporate account holders, car dealerships, insurance companies, and others. 

• ARMS - The ARMS system will receive/send transactions to ARMSAVeb to retrieving 
information regarding the automobiles. 

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this 
system as well. Each company will have the abiUty to initiate and manage their rentals through 
the use of this application. 

Pre-Conditions 

• The USER must be signed-on to the ARMSAVeb system. 

• The USER must have a reservation or open ticket selected. 

Flow of Events 

The Flow of Events will include the necessary steps to view and/or select the car class to apply to a rental 
reservation. 





1.5.2 Basic Flow 

The Basic Flow of the View Car Class use case includes all of the required steps to view and/or 
select a car class for a rental reservation. If a car class is selected, it will be used to populate rate 
information on a rental authorization. 

1. The USER will select View Car Class from the active reservation or open ticket. 

2. The system will display a car class detail screen. If the USER had previously selected a car 
class (for example, on the Create Reservation screen), the car class selected will be 
displayed. If no car class has been selected, the system will display the Standard car class. 

3. The USER will select the car class to apply to the reservation or open ticket. 

4. The system will return the USER to the active reservation or open ticket and populate car 
class information based on the car class selected. 

5. This ends this use case. 

1.5.3 Alternative Flows 

1.5.3.1 Select Alternate Car Class 

From Step 2 of the Basic Flow, the USER will have the ability to view an alternate car class. 
The car classes that will be available to view include: 

■ Economy 
" Compact 

■ Intermediate 

■ Standard 

■ Full Size 

■ Premiiun 

If the USER selects an alternate car class, the system will refresh and present the details of the 
new car class. 

1.5.3.2 Populate Car Class Rates 

If a rental branch location has already been selected prior to entering this use case, the selection 
of a car class will populate the rates that apply to the selected car class on the active reservation 
or open ticket This alternate flow returns the USER to Step 4 of the Basic Flow. 

1.6 Post-Conditions 

• If successM, the selected Car Class will be returned to the active reservation or open ticket. 

• If unsuccessM, the system state is unchanged. 





1.7 Special Requirements 

The additional requirements of the business use case are included here. These are requirements not 
covered by the flow as they have been described in the sections above. 

1. 7. 1 Modify Car Class Selection Results 

The USER may change the results of this use case as part of the active reservation or open ticket. 

1.8 Extension Points 

None. 
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2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

2.1 Car Class D etail Screen ^ ^'i^^^'^ ^ • ^ " ^^)) 

This screen ^viiil allow the USER to view detailed information about the rental company's car classes. The 
USER will also have the ability to select a car class to apply to a rental reservation / authorization. 






2.1.2 Car Class Details 

















Output 


20 


Car Class Name 




This should be the name of 
the currently selected car 




Output 


40 


Rental Company Name 






(Person Image) 


Output 


2 


Car Class Person 
Capacity 




This should provide the 
average person capacity of the 
selected car class. 


(Luggage 
Image) 


Output 


2 


Car Class Luggage 
Capacity 




This should provide the 
average luggage capacity of 
the selected car class 




Hidden 


255 


Car Class Image Source 




This should provide a picture 
of an example car within the 
selected car class. 




Output 


120 


Car Class Detail 
Description 




nris should provide a 
description of the selected car 
class. 


Economy 


Output 




Economy Car Class 




This should be a hyperlink to 
the Economy car class detail. 


Compact 


Output 




Compact Car Class 




This should be a hyperlink to 
the Compact car class detail. 


Intemediate 


Output 




Intermediate Car Class 




This diould be a hyperlink to 
the Intermediate car class 
detail. 


Standard 


Output 




Standard Car Class 




This should be a hyperlink to 
the Standard car class detail. 


Full Size 


Output 




Full Size Car Class 




This should be a hyperlink to 
the Full Size car class detail. 


Premium 


Output 




Premium Car Class 




This should be a hyperlink to 
the Premium car class detail. 





2. 1.3 Screen Function Definition 

This section includes the definitions for all functions that can be perfonned within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Select This Car Class 

The Continue screen function wiU allow the USER to select tiie car class to apply to a 
reservation. 

2.1.3.1.1 The Continue screen fiuiction is invoked through either a button click or 
through an Enter keysttoke. 



2.1.3.2 Previous 

The Previous screen function allows the USER to return to tiie previous screen. 
2.1.3.2. 1 The Previous screen function is invoked through a button click. 





3. Questions and Answers 

None. 




ARMS/Web 3.0 
Functional Design Specification 
Authorize a Request 



Version 1.1 



ARMSRs 
Authorize 



sign Project - Release 3.0 



Issue: vl.l 
Issue Date: 10/20/00 



Revision History 



Date \ 


Issue 


Description 


Ay«6or 


April 13, 2000 \ 

\ 


0.1 


Updated with Database Fields 


Cindy Bastean, Deb 
Ealick/ 


April 20, 2000 


vO.2 

\ 


Removed subdocuments 


Cinc^ Bastean 


May 10, 2000 


(K3 


Modified according to cross-team review 


Cin&y Bastean 


May 15, 2000 


0.3\ 


Added screen change to document 
according to cross-team review 


Dfebi Ealick 


June 8, 2000 


0.4 \ 


Updates for Iteration 2 > 


' Brian Weingart 


June 8, 2000 


0.4 \ 


Added data field information / 


Cindy Bastean 


June 14, 2000 


0.4 \ 


Added Zefer look and feel image for tlyi 
\Authorize Rental Detail / 


Amanda Banta 


July 3, 2000 


0.5 


(Ranged Screen information ^ 


Cindy Bastean 


July 13, 2000 


0.5 


UpHated Use Case and Screen Design 

^ / 

/ 


Brian Weingart, Mike 
Slater, Johnny Sands, 
Deb Ealick, Brent 
Armbruster and Cindy 
Bastean 


August 24, 2000 


1.0 


Updated Use Case. Ch^ges made based 
on feedback provided management 
reviewers. ^ 


Mike Slater 


September 26, 2000 


1.1 


Changes made bas^d on feedback provided 
by business lead4(with respect to the future 
state of Release^ .0. 


Amanda Banta, Aaron 
Foster, Mike Slater, Tim 
Weinstock 



Confidential / Enterprise Rent- A-Car © 2000 

Y:\APPS\#ARMS\yb\Application\ARMSWEBV3\@dkb\Functional Specs\MA-10-Aulhorize a Request\Functional Specs\MA-iO-FDS-ARMSWeb3.0vl.l.i 



Redesign Project - Release 3.0 



Issue: 
Issue Date: 10/2jif/00 



Table of Contents 



Authorize Request Use Case 

1 . 1 Appli^tion Overview 

1.2 Brief bfegcription 

1.3 Use Case lectors 

1.4 Pre-ConditiQns 

1.5 FlowofEvetks 

1.5.1 Acti\^ Diagram 

1.5.2 Basic Hpw 

1.5.3 Alternative Flows 

1.6 Post-Conditions \ 

1.7 Special Requirementk 

1.7. 1 Requirementsf^for Claim Type Authorizations 

1.7.2 Requirements fer editable fields based on reservation / tickeys 

1.8 Extension Points \ 

1.8. 1 MA-04 Send A Message 

1.8.2 MA-07 Additional Charges 

1.8.3 MA-16 Transfer Wok 

Screen Design 

2. 1 Authorize Rental Detail 

2.1.1 Screen Layout - Authoriz^ental Detail 

2.1.2 Authorize Rental Detail 

2.1.3 Screen Function Definition 



Confidential 

Y:\APPS\#ARMSWeb\ 



Enterprise Rent-A-Car © 2( 
ion\ARMSWEBV3\@dkb\Fimctional Specs\MA-10-Authorize aRequestWunctional SpecsMA-lO-lfc 



Issue; vl.l 



Authorize a Request 

1. Authorize Request Use Case 

1.1 Application Overview 

The following is a document used to illustrate the process for how a USER authorizes a direct bill request 
using ARMSAVeb 3.0. The intent for this release of the ARMSAVeb application is to reach a much wider 
audience. This application will target a Multi- Vendor, Multi-Segment, and International customer base. 

1.2 Brief Description 

This use case describes how a USER authorizes a direct bill request. 

1.3 Use Case Actors 

The following actors will interact with this use case: 

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to 
authorize a direct bill request. This use case refers to a USER in the role of a rental administrator. 
There are various types of customers that the USER would represent, which include corporate 
account holders, car dealerships, insurance companies, and others. 

• ARMS - The ARMS system will receive/send transactions to ARMSAVeb to confirm the direct 
bill request 

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this 
system as well. Each company will have the ability to initiate and manage their rentals through 
the use of this application. 

1.4 Pre-Conditions 

• The USER must be logged into the ARMSAVeb system. 

• The USER must have the authority to authorize a request. 

• At least one outstanding unauthorized direct bill request must be assigned that the USER may 
handle. 

• The USER must have selected an Unauthorized Direct Bill Request from the Review Action Items 
Screen or from the Search Results page. 

1 .5 Flow of Events 

The Flow of Events will include the necessary steps to make changes and updates to "Authorize Request" 





1.5.2 Basic Flow 



1 . The USER selects an outstanding direct bill to authorize. 

2. The system displays the Customer file. 

3 . The USER reviews the renter's information. 

4. The USER inputs a number of Authorized Amounts, days and required fields. 

5. The USER submits the Authorization. 

6. The system validates information in the Customer File. 

7. If the USER assigned to the Customer File is 'UNKNOWN' or "UNASSIGNED', the System will 
assign the Customer File to the current USER. 

8. The system will update the ARMSAVeb database with the Authorization. 

9. The System reads the USER profile to see if the confirmation page should display. 

10. If the profile indicates 'Show Confirmation Page', the System will display the confirmation page 

11. For non-Enterprise rentals, the authorization request is sent to the non-ERAC rental car company's 
rental system. 

12. This ends the use case. 

1.5.3 Alternative Flows 

1.5.3.1 View Notebook 

At step 3 of the Basic Flow, the USER can select to view the transaction history (Notebook) by 
selecting the Go To Notebook Hnk. 

1.5.3.2 Add Notes to Customer File 

At step 3 of tile Basic Flow, tiie USER can add notes to the Customer File by typing in the 
appropriate notes field on the Customer File page. 

1.5.3.3 Skip Customer File 

At step 3 of the Basic Flow, the USER can get out of the Customer File by selecting the skip 
button on the Customer File page. 

1. 5. 3. 4 Change Customer File 

At step 3 of the Basic Flow, the USER can make changes to the additional details of the Customer 
File. This is done by selecting the Add / Change link which will invoke an editable page with all 
♦appropriate information editable. 

1.6 Post-Conditions 

• If the use case was successfiil then the changes should go into effect immediately and the screen 
should revert back to the original screen of entry. 

• If the use case was successfiil, then the ARMSAVd) system will be notified of authorization 
changes. 

• If the use case was unsuccessful then the system state will be unchanged. 

1.7 Special Requirements 

1. 7. 1 Requirements for Claim Type Authorizations (Insurance Users Only) 

The following are a set of requirements surrounding the type of authorized amounts that are 
allovrable based on the Claim Type associated with a rental. These restrictions DO NOT APPLY 
to reservations that are submitted with a Direct BiUing Percentage of zero (0). 

1. 7. 1. 1 When the Claim Type selected is 'Insured', 'Theft', or 'Uninsured Motorist' 

1 .7. 1 . 1. 1 For insurance USERs, the reservation/rental must always include an 
Authorized Rate or both PoUcy Daily and Maximum Limits as defined by the renter's 
insurance policy. Zero (0) is an acceptable Policy Daily Limit. 



1.7. 1. 1.2 For insurance USERs, the reservation/rental must include an Authorized Rate 




or Policy Daily Limit if a Policy Maximum Limit is included. Zero (0) is an acceptable 
Policy Daily Limit. 

1. 7. 1.2 When the Claim Type selected is 'Claimant' (Insurance Users Only) 

1.7.L2.1 The reservation/rental must always include an Authorized Rate. 

1.7. 1.2.2 The reservation/rental may not include a Policy Daily/Maximum Limits 
selection. 

1. 7. 1.3 Requirements for editable fields based on reservation /ticket status 



1.7. 1.3. 1 Depending on the status of the Customer File the USER may change the 
following fields; 



Field Name 

(Depending on USER Segment) 


Unassigned/ 
Unauthorized 
Reservation/Ticket 


Assigned but 
Unauthorized 
Reservation or 
Ticket 


Authorized 
Ticket 


CLAM NUMBER 
(Insurance & Fleet) 
PURCHASE ORDER NUMBER 
(Dealership) 

CORPORATE CLASS NUMBER 
(Corporate) 


X 


X 


X 


CLAIM TYPE 
(Insurance) 
BILL TYPE 
(Dealership) 


X 


X 


X 


VEfflCLE CONDITION 


X 


X 


X 


DATE OF LOSS 
(Removed for corporate) 


X 


X 


X 


NSURED INFORMATION 


X 


X 


X 


RENTER INFORMATION 


X 






DATE RENTAL IS NEEDED 


X 






NUMBER OF AUTHORIZED 
DAYS 


X 


X 




DIRECT BILL PERCENT 
(Insurance Only) 


X 


X 


X 


POLICY LIMFTS 

(Insurance and Corporate Only) 


X 


X 


X 


AUTHORIZED RATE 


X 


X 


X 



If the Customer File is an Unauthorized Reservation, the USER can Reject the Authorization Request, 
Send a Message, and/or Transfer (Assign) the file to a USER. 





1.7. 1.3.2 If the status of the Customer File is an open ticket the following rales apply: 



Actions 


Authorized 


Unauthorized 


Authorized 




Reservation 


Reservation / 


Open Ticket 






Ticket 


Send Message 


X 


X 


X 


Extension 






X 


Terminate Rental 






X 


Cancel 

Authorization 


X 


X 




Transfer/Assign 
Adjuster 


X 


X 


X 


View Car Class 


X 


X 


X 



Extension Points 

An extension point indicates a link between this use case and another use case. Extension points associated 

with the use case are indicated below. Clicking on the extension point will open the related use case. 

1.8.1 MA-04 Send A Message 

The Send Message will be used to allow the USER to capture messages and diaiy notes associated 
with extending a rental. The USER can elect to either have the message sent to the rental 
company responsible for the reservation/authorization, or (Depending on the USER segment if this 
option is available) to store the note in the ARMSAVeb system without sending the message to 
rental company. All MESSAGES and DIARY NOTES captured must be related to a specific 
reservation/authorization. 

18.2 MA-07 Additional Charges 

The USER may choose to select the additional charges button that displays a page showing all the 
additional items at the branch with the branch charges displayed. The USER can select the items 
and enter in the authorized amoimts. 

1.8.3 MA-16 Transfer Work 

The USER may choose to transfer an authorization to a different USER in his/her ofiice or transfer 
the authorization to another USER in a different office. 

1.8.4 MA-08 View Car Class 

The USER may choose to view the car class. This button invokes the View Car Class use case. 

1.8.5 MA-17 Cancel Authorization 

The USER may choose to deny the authorization. When the USER selects the CANCEL button, it 
will invoke the Cancel Authorization use case to reject the authorization. 




2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen fiinctions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 
2.1 Authorize Renta l^ Detail (iAJi^ ^1^o^^r 5 1 , 1 ^5 ( q) - ( j 

This screen.>^ll allow the USER to work the currently selected authorization request. The USER 
(Depending on the USER segment) may set the authorization amounts and policy coverage limits or may 
assign the request to another USER. 



(ARMSAVeb 2.0) 



U Screen Layout -Authorize Ranfal DRfaii — <jp ^ ^\c\jf^-^ 

\T^U 1 n\ ' ■ ' ■ \ 



on- 





Claims Office; 001 



Hsnrilingfor You-self 



Authorize Direct Biif: for Hante, Tom Claim no. 765849322-01 

CUSTOMER FSLE 



Pjfect BiH Requested for; 



Poky Baity Tate/ j j 



VahfdB CjOKStmti } Select a Condit on 



Date ffentafn 



1 of 4 Action Items 



tatiim Type; I Select o Qaim Type j;J 
jtete to Rental Cowyanp 



Direct afi inquest fof HiBtte. Toirt*S3«& 



[ Change o.-Add| 

Hanks, Tom 
1735 N. Paulina St. 
Chicago, IL60B22 

BS^FtAl. SN)=08SUATi<»W: 

Rental Location: 

Enterprise Edgewater Branch 
5400 N. Ashland 
Chicago, IL 60622 
773-334-5400 



Home-: (773)564-6054 
Work: (773)395-6200 
Email:thanks@2efer.com 
Requested email confirmation 




nflin- 001 H-jndl'ng fur Y^irself 

Amhimra Direct BilhforH^nte, Um nammr ms^iBWau 



m^fA em R*qW5t««i Iw; Qwm JUwNf; 1765849322 001 

I <Jsy? ^ jCompacVJI 95 

Sfexmwm dollors* 



Owm Twe;|Select u Qaim Type ^ 
note <i> naftta> Cowpaitp ^ 



Oa*fr nf t nsr jjnnuQtv ^jl 2000 .T.I ,'„^|;^ 



Hanks, Tom 
1735 N. Paulina St. 
Chicago, IL 60622 



Rental Location: 

Enterprise Edgewater Branch 
5400 N. Ashland 
Chicago, IL 60622 
773-334-5400 

Direct Bill request for Hanks, Tom 4y23/00 



Home: (773)564-6054 
Work: (773)395-6200 
Email:thanks@zefer. com 
Requested email confimnation 





AurhfifiT-o Direct Bill: 



1 of 4 Action Items 



DirPCtPnReqt»$t*<ir«r; PMrBJw¥p9|*jr»B^ 17658^9322 001 BiHTWRf" 



" <layjt § ) CompacV21 95 ^ ^T^;^**^ . 



iftawe#N*ur, tsst.] Fttstj 



[ Change or Add ] 

Hanks, Tom 
1735 N. Paulina St. 
Chicago. IL 60622 



Rental Location: 

Enterprise Edgewatsr Branch 
5400 N. Ashland 
Chicago. IL 60622 
773-334-5400 

Direct Bill request for Hanks, Tom 4/23/00 



Home: (773)564-6054 
Work: (773)395-6200 
Email:thanks@zefer. com 
Requested email confinnatior 
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[ Change or Add ] 

Hanks, Tom 
1735 N. Paulina St. 
Chicago. IL 60622 

Rental Location: 

Enterprise Edgewater Branch 
5400 N. Ashland 
Chicago, IL 60622 
773-334-5400 

HOTPMOQX.: 

Direct Bill request for Hanks. Tom 4/23/00 



Home: (773)564-6054 
Work: (773)395-52CD 
Email:thanl<s@zefer. com 
Requested email confinnation 
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2. 1 2 Authorize Rental Detail 
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Screen Function Definition 

This section includes the definitions for all fiinctions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Sl<ip 

When clicked, the USER will be taken out of the use case without changing the current status of 
the request. Any changes made by clicking Change or Add and keying data in the bottom section 
will be saved. 

2.13.2 Process 

When clicked, the system will validate the input and accept the changes made to the customer file. 
The ARMS/Web database will be updated. The use case will then end and the USER will return 
to the process from which they came. 

2.13.3 Notebooi< 

When clicked, the USER will be taken to die Note Book section at the bottom of the screen to 
view all messages for this rental. 

2.13.4 Set Last Date 

When clicked, the system will terminate the rental. The USER vtill be prompted to enter a 
termination date for this rental. This coincides with the use case MA-17-Terminate Rental. 
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2.1.3.5 Transfer File 

When clicked, the USER will be taken to the Transfer File screen. This screen allows the USER 
to change the office or USER currently assigned to the customer ffle. The required information in 
the Extend Rental/Customer File wiU be passed to the Transfer File screen. Upon completion of 
the transfer, the USER will then be returned to the next action item or the profiled start page, 
depending on the screen from which the USER began. 

2.13.6 Change or Add 

When clicked, the system will refresh the current screen and make all editable fields in the bottom 
section (outside the gray box area) input capable. The changes on the top of the screen will not be 
lost. 

2.1.3.7 Top of page 

When clicked, the USER will be taken to the top of the current page. 

2.1.3.8 View Car Class 

When clicked, the USER will be taken to the View Car Class Use Case. No changes will be lost. 
Once the USER is finished with this use case, the USER will return to the Extend Rental Use 
Case. 
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Create Reservation 

1. Create Reservation Use Case 

1.1 Application Overview 

The following is a document used to illustrate the process for creating a reservation using ARMS Web 3.0. 
The intent for this release of the ARMS Web application is to reach a much wider audience. This 
apphcation will target a Multi-Vendor, Multi-Segment, and International customer base. 

1.2 Brief Description 

This use case describes how a USER would create a rental reservation in the ARMS Web system. When 
creating a reservation, the USER is also creating an authorization for payment. The USER may also 
submit a reservation without authorizing payment. 

1.3 Use Case Actors 

The following actors will interact with this use case: 

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to 
create an authorized reservation. This use case refers to a USER in the role of a rental 
administrator. There are various types of customers that the rental administrator would 
represent, which include corporate account holders, car dealerships, insurance companies, and 
others. 

• ARMS - The ARMS system will receive/send transactions to ARMS Web to create and confirm 
the reservation. 

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this 
system as well. Each company will have the abihty to initiate and manage their rentals through 
the use of this application. 

1.4 Pre-Conditions 

• The USER must be signed in to the ARMS Web system. 

• The USER must have the authority to create a reservation. 

1.5 Flow of Events 

The Flow of Events includes all steps necessary to create a reservation using the ARMS Web system. 





1.5.2 Basic Flow 



The Basic Flow of the Create Reservation use case includes all of the required steps for a new reservation 
to be created in the ARMS Web system. Shadowed boxes in the Activity Diagram indicate the Basic 
Flow. 

1 . The USER selects to create a reservation from the top navigation menu. 

2. The system prompts the USER to enter initial information about the renter (Depending on the 
user segment): 

• Corporate Class Number or Claim Number (The use case will refer to this as 'Reference 
Number') 

• Bill Type 

• Renter First Name 

• Renter Last Name 

• Rental Company 

• Telephone Number or Postal Code where the renter would like to be picked up 

3. The USER enters initial information about the renter. 

4. The USER submits the initial reservation information to the system. 

5. The system will validate the initial information entered by the USER' . 

6. The system will perform a search for previous authorizations that may correlate directly to the 
rental reservation that the USER is beginning to establish. The system will search for two key 
types of records; 

• Unauthorized Request Matches 

An Unauthorized Request is defined as a rental Authorization Request that is generated 
when The Rental Company creates a reservation or contract for the customer that has 
not been approved. This search helps to prevent the USER from creating a new 
reservation for a customer that has an outstanding Unauthorized Request in the ARMS 
system. The Unauthorized Request search is completed using the first three characters 
of the Renter Last Name and is limited to unauthorized requests (requests in imassigned 
or direct bill request statuses) for the selected Office. If matches are found, the 
Unauthorized Request/Authorized Request Search Matches Alternative Flow will be 
invoked. 

• Authorized Matches 

Reference mmibers that have already been associated with a rental reservation or 
contract (i.e.. Authorized Rentals) should be brought to the attention of the USER to 
help prevent over-authorization situations. The system will search for an exact 
corporate class number match on any reservation or ticket (open or closed) related to the 
company in the last six months. This search will be completed using the exact 
Reference Number on all authorized requests (requests in any status other than 
imassigned or direct bill request). 

If no matching records are found, the Basic Flow continues. 

7. The system will retrieve a rental branch location where the rental is needed based on the 
Telephone Number or Postal Code entered by the USER If no location is found, a message 
should be generated notifying the USER that no location was available for the search criteria and 
that Claims Coimection will handle the reservation (include the search criteria in message). 



See section 1.5.3. 1 Initial Reservation Infonnation Invalid in Alternative Flovps on page 4 for validation roles. 
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8. The system will retrieve the current applicable rates for that rental branch location. If no rental 
branch location is available, the system will display an open text box to allow the USER to type 
in a rate. 

9. The system will display the Quick Reservations screen. 

10. The USER will enter the reservation information. 

1 1. The USER submits the reservation to the system. 

12. The system will validate the reservation information submitted by the USER^. 

1 3 . The system updates the database. 

14. The system sends the reservation to ARMS. 

15. The system will display the reservation confirmation to the USER. The reservation confirmation 
will not include a confirmation number, but will incorporate a message that The Rental Company 
has received the reservation. 

16. If the reservation is a non-Enterprise reservation, than the transaction is electronically 
transmitted to the intended rental car company's rental system. 

17. This ends this use case. 



1.5.3 Alternative Flows 

The Alternative Flows of this use case can occur when certain conditions exist or specific USER feedback 
is provided. 

1.5.3. 1 Initial Reservation Information Invalid 

If the initial reservation information is invalid (Step 5 of the Basic Flow), the system should 
present an error message to the USER and force the USER back into Step 2 of the Basic Flow. 



1.5.3.1.1 It will be considered invalid if the Reference Number, Renter First Name, Renter Last Name, Rental 
Company, or Where Needed Value (Postal Code or Telephone Number) have not been included. 

1.5.3. 1.2 It vrill be considered invalid if the 'where needed' search criteria is a U.S. or Canadian telephone 
number and the first three digits (i.e., area code) meet the criteria below: 

• OXX 

• IXX 

• The second and third digits equal (e.g., 800, 877, 888, etc.) 
Where X equals any digit 0 through 9. 

1.5.3.1.3 It will be considered invalid if the 'where needed' search criteria is a U.S. or Canadian telephone 
number that does not consist of 10 digits. 

1.5.3. 1.4 It will be considered invalid if the 'where needed' search criteria is a U.S. postal code that does not 
consist of 5 or 9 digits. 



See section 1.5.3.3 Reservation Information Invalid in Atternative Flows on page 5 for validation rules. 




1.5.3.1.5 It will be considered invalid if the 'where needed' search criteria is a Canadian postal code that does not 
consist of 6 alphanumeric characters in the format AXAXAX where A is an alpha character and X is a digit 
between 0 and 9. 

1.5.3.2 Unauthorized Request/Authorized Request Searcti Matches 

If either the search for Unauthorized Requests or the search for Authorized Request matches 
returns a positive result (Step 6 of the Basic Flow), the matching records will be presented to the 
USER. The matching records should be provided in summary form, and be distinctly identified 
as either Authorized Request matches or potential Unauthorized Request matches. 

• For Authorized Request matches, the USER will have the abiUty to select the Authorized 
Request and move into the MA-19 View Customer File use case to view the details of 
the previously authorized rental. The USER will have the option of continuing or 
canceling this use case from the MA-19 View Customer File use case. 

• For Unauthorized Request matches, the USER will have the ability to select the 
Unauthorized Request and move into the MA-10 Authorize Request use case to review 
and/or perform operations on the Unauthorized Request. 

If the customer does not appear as an Unauthorized Request or Corporate Class Number match, 
the USER can select to continue to Step 7 of the Basic Flow. 

1.5.3.3 Reservation Infonvation Invalid 

If an error is discovered in the validation of the reservation information submitted by the USER 
(Step 12 of the Basic Flow), the system will present the USER with an error message and return 
them to Step 9 of the Basic Flow (NOTE: If the USER submitted information from the Detailed 
Reservation screen, they should be returned to the Display Detailed Reservation Alternative 
Flow above). If the error is specific to a data field within the form, the field should be 
highlighted and the error described. 

1.5.3.3. 1 It will be considered invalid if the Reference Number, Renter First Name, Renter Last Name, Vehicle 
Condition, Rental Location, Authorized Number of Days, and at least one Renter Telephone number have not been 
included. 

1.5.3.3.2 It will be considered invalid if the customer has established Reference Number editing and the Reference 
Number format does not meet the requirements of the customer's Reference Number definition. Reference Number 
definition is completed as part of the company profile^. 

1.5.3.3.3 It will be considered invalid if any field identified as REQUIRED in the company/office profile is not 
included. 

1.5.3.3.4 It will be considered invalid if any data entered violates the data type as specified by the ARMS Web 
database (i.e., alpha characters in a numeric field). 

1.5.3.3.5 A warning will be presented to the USER if any defined limits identified in the company/ofl5ce/user 
profile are exceeded (e.g.. Maximum Number of Days Authorized). The system will allow the USER to submit the 
authorization from the warning. 



Claim Number fonnat definition will be defined in some cases in botii the ARMS Web system and in the ARMS/400 system (e.g.. Nationwide, 
GEICO). Claim number definition will have to be maintained in BOTH systems in cases where this overlap exists. We are unable to reuse the claim 
number format definitions due to technical complications. 
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1.5.3.3.6 It will be considered invalid if the Authorized Number of Days is included and is less than zero (0). 

1.5.3.3.7 It will be considered invalid if the Date of Loss is greater than the current date. 

1.5.3.3.8 It will be considered invalid if the first three digits (i.e., area code) of any U.S. or Canadian telephone 
number meet the criteria below: 

. OXX 

• IXX 

• The second and third digits equal (e.g., 800, 877, 888, etc.) 
Where X equals any digit 0 through 9. 

1.5.3.3.9 It will be considered invalid if a U.S. or Canadian telephone number does not consist of 10 digits. 

1.5.3.3. 10 It will be considered invalid if a U.S. postal code does not consist of 5 or 9 digits. 

1.5.3.3. 1 1 It will be considered invalid if a Canadian postal code does not consist of 6 alphanumeric characters in 
the format AXAXAX where A is an alpha character and X is a digit between 0 and 9. 

1.5.3.3.12 It will be considered invalid if an E-mail address is included that does not include an '©'character. 

1.5.3.4 Cancel Use Case 

The USER should be capable of canceling the use case at any point prior to the submission of the 
reservation to the ARMS Web database. The USER should be returned to the previous 
activity/page that the USER was on prior to entering this use case. 

1.6 Post-Conditions 

• If successM, a reservation authorization is sent to ARMS. 

• If luisuccessfiil, the system state will be unchanged. 

1.7 Special Requirements 

1. 7. 1 Requirements for Reference Number Formatting 

The following statements are a set of requirements for providing custom reference number formatting for 
a customer. The ARMS Web system Tvill allow customer companies to define a specific layout or format 
that they use as their standard reference number format, so that the reference number field used in the 
system is presented as separate fields and are easily recognizable and 'intuitive' to the USER. These 
requirements will be implemented to all system fimctions where the customer reference number is used. 
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MAA Customers must have the ability to define their reference number format (and in some cases 
validations on specific portions of the reference number format) as part of the company profiie. 
More than one reference number format can be stored per company, and each reference number 
format definition must have a unique identifier/name. The selection of which reference number 
format to use should be defined as part of the office profile using the reference number format 
unique identifier/name. 

1.7 A. 2 Reference numbers will be defined in 'segments'. Each segment will be presented to the USER 
as a separate field. For example, if the reference number format for the COMPANY were 45- 
A7456-1207, the reference number fonvat would be denned to the system as a 2-character 
numeric field, a 5-character alphanumeric field, and a 4-character numeric field. 

1. 7. 1. 3 Customers must have the ability to define a set of 'valid values' for any given segment of the 
reference number fonvat. Valid Values allow the customer to dictate what the valid entries for a 
given reference number segment would include. For example, if the second segment in the 
customer's reference number format must be a state abbreviation, the customer could define 
valid values for that segment as 'AU, 'AR; 'AK; etc. If the USER does not enter one of the valid 
values, an error would be generated to notify the USER to enter a "valid' value. If no valid values 
are included for a reference number segment, all entry in to the field will be considered valid 
(assuming that the data type is correct). If valid values are specified, entry into the reference 
number segment MUST MATCH ONE OF THE VALID VALUES IDENTIFIED. 

1.7.1.4 The system will display the reference number field(s) as it is described by the reference number 
format definition for the office. 

1. 7. 2 Requirements for Finding Rental Location 

Below are the requirements for finding a rental location, across multiple rental car companies, in the 
ARMS Web system. ARMS Web will resolve a rental location and pass the location to ARMS for routing 
(which is a deviation from current state handling). These requirements were derived from the current 
state business requirements for the ARMS locator system. 

1. 7.2. 1 ARMS Web will always return a Rental Company's branch location for a reservation. For all 
ARMS Web reservations, the following rules for finding a rental location apply: 

1.7.2. 1. 1 For United States locations, the locator will search a 50-mile radius around the renter's phone number 
or postal code for the closest branch that accepts ARMS reservations. 

1.7.2. 1.2 For International locations, the locator will search a 50-mile radius around the renter's phone number or 
postal code for the closest open branch that accepts ARMS reservations. If no open branches are found, the closest 
branch that accepts ARMS reservations should be returned. 







17.2.2 When the rental branch location is determined, the system will retrieve the name, shipping 
address, telephone number and rates of the rental branch location and present them to the 
USER on the Create Reservation screen(s). 

1. 7.2.3 The system will only display Claims Connection (7680) as the location (with no rates) when no 
location can be found within the 50-mile radius. If Claims Connection is displayed, a message 
should be included to indicate that no rental branch location was found within a 50-mile radius of 
the search criteria, and Claims Connection will ensure that the reservation is handled 
appropriately. 

1. 7. 3 Requirements for Routing a Reservation 

When a reservation is submitted to the ARMS Web system, routing of the reservation is required to ensure 
that the renter is called within two hours to confirm rental details. Routing is done AFTER the 
reservation has been submitted to the ARMS Web system, and is transparent to the USER . The 
reservation can be routed to the selected rental branch, to Claims Connection, or to a regional call center 
based on the following rules: 

NOTE: These requirements were derived from the current state business requirements for the ARMS 
locator system. 

1. 7.3. 1 The system should automatically route submitted reservations to Claims Connection between 
Friday 11:00pm and Sunday 11:00pm, regardless of whether the selected rental branch location 
is open or not. 

1. 7.3.2 The system should determine if the selected rental branch location on a submitted reservation is 
open or closed. 

1.7.3.2.1 If the selected branch is open, the submitted reservation should be routed directiy to the rental branch 
location (except in cases where a regional call center exists, see 1.7.3.3 below). 

1.7.3.2.2 If the selected rental branch location is closed, the system will determine if the company that submitted 
the reservation has established afler-homs handling of reservations. If the company has not established after-hours 
handling, the reservation is routed to the selected rental branch location (except in cases where a regional call 
center exists, see 1.7.3.3 below). If the company has established afler-hours handling, the following rules apply; 



1. The system will check the hours of availability for Claims Connection. Claims 
Connection Hours are 5:00 am. - 1 1:00 p.m. CST, 7 days a week". 

a. If Claims Connection is open, the reservation will be routed to Claims 
Coimection. (The insurance company customer. National Marketing and the 
Claims Connection Manager mil determine whether or not Claims Connection 
makes a courtesy call to the renter). 

b. If Claims Connection is closed, the closest branch hours are checked to see if 
they will be open within 8 hours. If the branch will be open in 8 hours, the 
reservation will be routed to the rental branch location (except in cases where a 
regional call center exists, see 1.7.3.3 below). If the branch will not be open in 
the next 8 hours, the reservation will be routed to Claims Coimection. 



1. 7. 3. 3 The system should determine if the selected rental branch location on a submitted reservation 



^ Although we receive reservations 24 hours/day, 7 days/week, we do not route them between 1 1 :45pm and 4:30am (CST). The only exception I 
is Saturday ni^t to Sunday. 
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has a regional call center. 

1.7.3.3 .1 If the selected rental branch location has a call center to handle customer callbacks, the reservation 
should be routed to the call center. 



1.7.3.3.2 If the selected rental branch location does noLhave a call center to handle customer callbacks, the 
reservation should be routed to the rental branch location. 



1. 7.3.4 The system should provide specific feedback indicating the reason a reservation was re-routed 
when the Authorization Confinnation is received This will allow the USER to be aware of the 
reason for the change of location if they access the reservation while it is owned by someone 
other than the rental branch location selected when the reservation was originally submitted. 

1.7.3.4. 1 If the reservation is re-routed to Claims Connection because the selected rental branch location was 
closed, the system should provide a message (that will be accessible through the diary notes/notebook) that states 
the reservation was routed to Claims Connection because the rental branch location was closed when the 
reservation was submitted. 



1.7.3.4.2 If the reservation is re-routed to a regional call center to expedite the callback process, the system should 
provide a message (that will be accessible through the diaiy notes/notebook) that states the reservation was routed 
to a regional call center to expedite the renter callback process. 



1.7.3.5 The system should include a message/note with the group/branch number and address of the 
rental branch location selected by the USER if the reservation is routed to any location (i.e., 
Claims Connection or otherwise) other than the rental branch location selected by the USER. 



1. 7. 4 Maintenance of Source Systems 

This use case requires that information in the existing Locator and Special Instructions (AS/400) 
databases be kept current and it is assumed that the group responsible for maintaining these databases will 
continue to do so in the future. Locator is used to retrieve Rental Branch Location information, and 
Special Instructions is used to retrieve rate information for a selected rental branch location. 




Extension Points 

An extension point indicates a link between this use case and another use case. Extension points 
associated with the use case are indicated below. 



1.8.1 MA-10 - Authorize Request 

The Authorize Request use case will be used to allow the USER to view and perform operations on an 
outstanding Unauthorized Request. The USER will not be returned to this use case on completion of the 
Authorize Request use case. 

1.8.2 MA-19 - View Customer File 

The View Customer File use case will be used to allow the USER to view the customer file when a 
matching authorized request is found and selected. The USER will have the option of ending the use case 
or be returned to Step 9 of the Basic Flow on completion of the View Customer File use case. 

1.8.3 MA-02- Find Rental Location 

The Find Rental Location use case will be used to allow the user to find one or more alternate rental 
branch locations that can provide service to the customer. The USER should be returned to Step 9 of the 
Basic Flow upon completion of the Find Rental Location use case. If the USER selects a rental branch 
location, branch information (i.e., address, phone) should be returned and the appropriate fields should be 
populated on the Reservation screen. 



1.8.4 MA-04-Send Message 

The Send Message use case will allow the USER to send a message to the Rental Company branch 
regarding the reservation, or select to store the message text with the reservation as a diary note (which is 
not sent to the branch). The USER should be returned to Step 9 of the Basic Flow upon completion of the 
Send Message use case. 



1.8.5 MA-07-Additional Charges 

The Additional Charges use case will be used to add special charges to the reservation being created by 
the USER . The USER should be returned to Step 9 of the Basic Flow upon completion of the Additional 
Charges use case. Any Additional Charges captured should be returned and applied to the reservation. 
The existence of Additional Charges should be reflected on the reservation screea 

1.8.6 MA-08-View Car Classes 

The View Car Classes use case will be used to allow the USER to view details about and select a car class 
to apply to a reservation. Details will include the average number of passengers and luggage items that 
can be served by a vehicle in the specific car class. The USER should be returned to Step 9 of the Basic 
Flow upon completion of the View Car Classes use case. The car class selected by the USER should be 
applied to the reservation. 





Screen Design 



A definition of the screen layout(s), screen data fields, and screen fiinctions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

Initial Reservation Screen 

The Initial Reservation screen provides the user interface and functions to support Steps 2 through 4 of 
the Basic Flow. The information captured on this screen will allow the system to perform several 
background search activities, and help to better construct the Quick/Detailed Reservation screen. All 
information captured on the Initial Reservation screen is required to create a new reservation, and is 
reused later in the reservation creation ^ce^^ 1 
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2. 1.2 Screen Field Definition 



I Screen Liinei 


Text 


Size 

m 


Screen Field Name 

IliBffliBBfBHl 


Data Field 


Renter First Name is a required field 


20 


Renter Last Name 


Last Name 


Renter Last Name is a required field 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Text 


30 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Number, 
PO#, CC§ 


'Reference' Number is a required field. 

'Reference' number should be presented 
in separate fields to correspond to the 
reference number format (segments) that 
has been defmed by the USER profile. 

hisurance User - Claim Number 
Fleet User - Claim Number 
Dealership User - Purchase Order 
Number 

Corporate User - Corporate Class Number 


Claim Type 
Bill Type 


Combo Box 


20 


Rental Type 
Description 


Rental type 
description 


The values of the Rental Type field for the 
Insurance user class are: 'Insured', 
'Claimant', 'Theft' and 'Uninsured'. The 
defauh value is '-Select Claim Type-'. 

Claim Type is a required field. 




Text 


15 


Where Needed 


Day Phone 
or Zip Code 


Where Needed Value is a required field. 


Postal Code 


Button 


1 


Where Needed 
Postal Code 
Indicator 


NOT 
STORED 


If the Where Needed Postal Code 
Indicator is set, the Where Needed Value 
should pre-populate the Renter Zip/Postal 
Code on the Quick/Detailed Reservation 


Phone 


Radio 
Button 


1 


Where Needed 

Telephone 

Indicator 


NOT 
STORED 


This should be the default radio button 
selected. 

If the Where Needed Telephone Indicator 
is set, the Where Needed Value should 
pre-populate the Renter Phone Number 1 
on the Quick/Detailed Reservation screen 



2.1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. This 
includes operations invoked by button clicks, specific shortcut keysti-okes, or other actor activity. 

2. 1. 3. 1 Create Reservation 

The Create Reservation screen fimction will aUow the USER to submit the information on the 
Initial Reservation screen and move on in the create reservation process. The system will use 
this information to perform background searches for Unauthorized Requests and Corporate Class 
Number Matches, and to build the Quick/Detailed Reservation screen appropriately. 

2.1.3.1. 1 The Create Reservation screen function is invoked through either a button click or an Enter keystroke. 



L 1.3. 1.2 The information captiued on the Initial Reservation screen will be used to pre-populate the 




corresponding fields on the Quick/Detailed Reservation screen. 



2. 1.3.1.3 If the information submitted to the ARMS Web application is invalid or incomplete, this screen fimction 
should prompt the USER with an error. The error should be specific as to the cause of the failure. All information 
previously entered should remain populated in each field, with the problem field highlighted or otherwise 
identified. 

2.2 Authorization Matches Found Screen 

The Authorization Matches Found screen provides the fimctions to support the Unaulhurizeil 
Request/Authorized Request Search Matches altemativevilow 
<ff ^ sorts fe.TSUj-te/ 
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2. 2. 2 Screen Field Definition 



Htoidling for: 


Output 


35 


User Name 


First Name 
+ Last 


Should be presented as User First Name + 
User Last Name 


Office 


Combo Box 


10 


Office Location 


external 

organization 

abbreviated 


The values presented in the Office 
Location list should be limited to the 
offices that the user has been granted the 
authority to create a reservation. 

The default selection is the last selected 
office location. If the user has not 
selected an office, the default selection is 
the user's default office as defined in the 
user profile. 

Office is a required field 


Renter Name 


Output 


35 


Renter Name 


First Name 
+ Last 


Should be presented as 'Renter Last 
Name + "," + Renter First Name' 

Should provide a hyperlink to the 
corresponding Authorize Request record 
(see MA-10 Authorize Request use case). 

This field is in the "Unauthorized Request 
Matches" section of the "Authorization 
Matches Found" screen 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Output 


30 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Insurance 

Claim 

Number, 

?o#,cc# 


Should provide a hyperlink to the 
corresponding Unauthorized Request 
record. 

This field is in the "Unauthorized Request 
Matches" section of the "Aufliorization 
Matches Found" screen 

Insurance User - Claim Number 
Fleet User - Claim Number 
Dealership User - Purchase Order 
Number 

Corporate User - Corporate Class Number 


Status 


Output 


15 


Authorization 
Status 


Status 
Description 


This field is in the "Unauthorized Request 
Matches" section of the "Authorization 
Matches Found" screen 
















Renter Name 


Output 


20 


Renter Name 


First Name 
+ Last 
Name 


Should be presented as Renter Last Name 
+ Renter First Name 

Should provide a hyperlink to the 
corresponding Customer File. 

This field is in the "Authorized Request 
Matches" section of the "Authorization 
Matches Found" screen 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Output 


30 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Insurance 
Claim 
Number, 
P0#, CC# 


Should provide a hyperlink to the 
corresponding Customer file. 

This field is in the "Reference Number 
Matches" section of the "Authorization 
Matches Found" screen 

Insurance User - Claim Number 
Fleet User - Claim Number 
Dealership User - Purchase Order 
Number 

Corporate User - Corporate Class Number 


Claim Type 
Bill Type 


Output 


20 


Rental Type 
Description 


Rental type 
description 


This field is in the "Reference Number 
Matches" section of the "Authorization 
Matches Found" screen 

Insurance User - Claim Type 
Fleet User - Claim Type 
Dealership User — Bill Type 


Status 


Output 




Authorization 
Status 


Status 
Description 


This field is in the "Reference Number 
Matches" section of the "Authorization 
Matches Found" screen 


Authorized Amount 


Output 


9 


Authorized Total 
Amount 


CALCULA 
TED 


This field is in the "Reference Number 
Matches" section of the "Authorization 
Matches Found" screen 



2. 2. 3 Screen Function Definition 

This section includes the definitions for all fimctions that can be performed within the screen. This 
includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity. 

2.2.3. f New Reservation 

The New Reservation screen function button will allow the USER to close/continue beyond the 
Authorization Matciies Founds screen. 



2.2.3. 1. 1 The New Reservation screen luncdon is invoked through either a button click or through an Enter 
keystroke. 




Quick Reservation Screen 

The Quick Reservation screen provides support for Step 9 of the Basic Flow. 

IMPORTANT NOTE: This is the minimum allowable set of fields on the Quick Reservation screen. 
The Quick Reservation screen will also include any fields indicated as QUICK RESERVATION in the 
company/office profile! See the Detail Reseryafion,screen for all available fields 
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Output 


35 


User Name 


First Name 
+ Last 
Name 


Should be presented as 'User First Name 
+ User Last Name 


Office 


Combo Box 


10 


Office Location 


external 

organi2ation 

identifier 


The default value should be the primary 
office of the current user. 

The values presented in the Office 
Location list should be limited to the 
offices that the user has been granted the 
authority to create a reservation. 

If changed, the system should 
automatically refresh the screen and 
update the "Handling for" list to the users 
in the newly selected office with the 
ability to create a reservation 


Handling for 


Combo Box 




Handling for 


First Name 
+ Last 


The combo list should include the users 
for the selected office location that have 
the authority to create a reservation. 

The default value should be 'Yourself 

The handling for users should be 
presented as User Last Name + User First 
Name in alphabetical order 


Claim Number 
Purchase Order 
Number 
Corporate Class 
Number 


Text Box 


30 


Claim Numbo: 
Purchase Order 
Number 
Corporate Class 
Number 


Insurance 
Claim 
Number, 
PO#, CC# 


Should be populated by the Reference 
Number entered on the Initial Reservation 

Reference number should be presented in 
separate fields to correspond to the claim 
number format (segments) that has been 
defmed by the USER profile. 

If changed, the system should validate that 
no matching reference numbers exist (i.e., 
reference number matching). The user 
should be notified if a match exists. 

Reference Number is a required field. 

Insurance User - Claim Number 
Fleet User - Claim Number 
Dealership User - Purchase Order 
Number 

Corporate User - Corporate Class Number 
















Bill Type 






Rental Type 
Description 


Rental type 
description 


Should be populated by the Rental Type 
selected on the Initial Reservation screen. 

The values of the Rental Type field for the 
Insurance user class are: 'Insured', 
'Claimant', 'Theft', and 'Uninsured'. 
Claim Type is a required field 


Vehicle Condition 


Combo Box 


20 


Vehicle Condition 


Driveable 
Flag + 
Repairable 
Flag 


The values of the Vehicle Condition field 
should include: 'Driveable', 'Non- 
Driveable', and 'Total Loss'. 

The default value should be '-Select 
Vehicle Condition-'. 


Renter First Name 


Text 


15 


Renter First Name 


First Name 


Should be populated by the Renter First 
Name entered on the Initial Reservation 

If the Renter First Name changes, and an 
exact / Unauthorized request match exists 
on the Renter First Name + Renter Last 
Name combination, the user will be 
notified of this match. 

Renter First Name is a required field. 


Renter Last Name 


Text 


20 


Renter Last Name 


Last Name 


Should be populated by the Renter Last 
Name entered on the Initial Reservation 
screen. 

If the Renter Last Name changes, and an 
exact Unauthorized request match exists 
on the Renter First Name + Renter Last 
Name combination, the user will be 

Renter Last Name is a required field. 




Combo Box 


10 


Renter Phone Type 
1 




The combo list should include the values: 
'Home', 'Work', 'Mobile', and 'Pager' 

The default value should be 'Select Type' 




Text 


15 


Renter Phone 


Day Phone 


If the Where Needed criterion entered on 
the Initial Reservation or Find a Rental 
Location screen was 'Telephone', the 
Where Needed Value from the screen 
should be populated in this field. 

At least one renter phone number is 
required. 




Text 


5 


Renter Phone 
Extension 1 


Renters Day 

Phone 

Extension 


N/A 




Send email 
confinnation to the 
renter 



Renter Postal Code 



email Confirmation 
Indicator 



Authorized 
Number of Days 



Number Of 
Days 

Authorized 



If the Where Needed criterion entered on 
the Initial Reservation or Find a Rental 
Location screen was 'Postal Code', the 
Where Needed Value from the screen 

should be populated in this field. 

N/A 

This field will default to unchecked. 



The Number of Days is a required field. 



Policy Daily Limit 

d Policy 
Maximum 



Dollars Per 
Day 

Covered + 

Max$ 

Covered 



The combo list should include the policy 
daily and maximum limits as defined in 
the company/ofEce profile. 

The policy limits should be presented as 
'Policy Daily Limit + "/" + Policy 
Maximum Limit" 



This field should default to 'Select Policy 
Limits' if the Claim Type is 'Insured', 
'Uninsured Motorist', or 'Theft'. 

If the Claim Type is 'Claimant', this 
field should NOT be displayed. 

'Othei" should be a selection in the list of 
options. If selected, the system will 
automatically replace the combo box with 
an open text box to allow the USER to 
type in a Daily Policy Limit, and a second 
open text box to allow the USER to type 
I in a Maximum Policy Limit 




Authorized Rate 



Vehicle 
Rate 



This field should be a combo box that lists 
all of the rates and car classes for the 
rental branch location in the format 'Rate 
+ " " + Car Class' 

'Other' should be a selection in the list of 
options. If selected, the system will 
automatically replace the combo box with 
an open text box to allow the USER to 
type in a rate. A combo box should also 
be included that allows the USER to 
select a car class with selections to 
include 'Economy', 'Compact', 
'Intermediate', 'Stanard', and 'Full Size'. 

If the reservation is for an 'Insured', 
'Uninsured', or 'Theft' Claim Type, the 
default selection for the field should be '- 
Policy Limits-' 

If the reservation is for an 'Claimant' 
Claim Type, the default selection for the 

field should be '-Select a rate-'. 

Should include the Additional Charge 
Description, the Additional Charge Value, 
and the Additional Charge Type. More 
than one additional charge can exist 



Authorized Total 
Amount 



Authorized Direct 



Authorized Total 
Amount 



CALCULA 
TED 



Rental Location 



Rental Location 
Branch Name 
Rental Location 

Address 

Rental Location 

Address 

Rental Location 

City Name 

Rental Location 
Postal /Zip Code 



Address 
Address 



The Direct Bill % should default to 100%. 

The Direct Bill % is a required field 

The authorized total amount field should 
show the total amount (w/o taxes and 
gov't surcharges) authorized based on the 
Number of Days Authorized, Rate, Policy 
Limits, and Direct Bill percent entered by 
the user. 

This field will calculate the total amount 
to be authorized (based on entry) when 
the USER clicks the Calculate screen 

function. 

N/A 





Output 


3 


Rental Location 
State / Province 
Code 


State 


N/A 




Output 


20 


Rental Location 
Telephone Number 


Telephone 
Number 


N/A 


Add the cmrent 
location to my list 


Checkbox 


1 


Add to Favorites 
Indicator 


NOT 
STORED 


Should default to false (unchecked). 

If checked, the system should add the 
current rental branch location to the 
favorites list in the user profile on the 
basis of the reservation. The branch 
location address will appear in the combo 
box on subsequent attempts until a 
description 


Favorite Locations 


Combo Box 


30 


Favorite Location 


location 
name 


The combo list should include the 
descriptions of each favorite location as 
identified in the user profile. 

This field should default to '-Select a 
Favorite Location-'. 

If a favorite location is selected, the 
application will instantly retrieve the 
favorite location and refresh the 
reservation screen. 


Note to Enterprise 


Text 


400 


AuthoriTation 
Message 


message 
text 


N/A 


Note to Self Only 


Text 


400 


Diary Note 


diary note 
text 


The system will store the text entered into 
this field in the ARMS Web database with 
the authorization, but the message will not 
be sent to the branch. 



2.3.3 Screen Function Definition 

This section includes the definitions for all fimctions that can be performed within the screen. This 
includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity. 

2.3.3.1 More Locations 

The More Locations screen function allows the USER to select a different rental branch location 
using the Find Rental Location use case. Invoking this screen fiinction will launch the USER into 
the Find a Rental Location use case. 



2.3.3. 1. 1 The More Locations screen fiinction is invoked through a button click. 



2. 3. 3. 2 Additional Charges 

The Additional Charges screen fiinction allows the USER to add, view, and modify any 
additional charges that they might authorize for a rental reservation (e.g., CDW). Invoking this 
screen fiinction will launch tiie USER into the Additional Charges use case. 




2.3.3.2.1 The Additional Cliarges screen function is invoked through a button click. 



2.3.3.3 View Car Class 

The View Car Class screen function allows the USER to view and select a Rental Car Class to 
apply to a reservation. Invoking this screen fiincfion will launch the USER into the View Car 
Classes use case. 

2.3.3.3. 1 The View Car Class screen fiinction is invoked through a button click. 

2. 3. 3. 4 Select a Favorite Location 

The Select a Favorite Location screen fiinction allows the USER to change the rental branch 
location to one of the rental branch locations identified as a 'favorites' in their USER profile. 

2.3.3.4. 1 The Select a Favorite Location is invoked by selecting a value from the Favorite Locations drop-down 
list. The system should automatically retrieve the favorite location (and rates) when the value of this field is 
selected. 

2.3.3.5 Confirm Reservation 

The Confirm Reservation screen fiuiction allows the USER to submit all reservation 
information to the ARMS Web system, which will create a new reservation. 

2.3.3.5. 1 The Confirm Reservation screen fimction is invoked either through a button click or by an Enter 
keystroke. 

2.3.3 .5.2 If the information submitted to the ARMS Web application is invalid or incomplete, this screen fimction 
should prompt the USER with an error. The error should be specific as to the cause of the failure. All information 
previously entered should remain populated in each field, with the problem field highlighted or otherwise 
identified. 

2.3.3.6 Cancel 

The Cancel Reservation screen fimction will allow the USER to leave the screen and return to 
their ARMS Web start page. No information is saved and no reservation is created. 

2.3.3.6. 1 The Cancel screen fimction is invoked through a button click. 




Reservation Confirmation Screen 

The Reservation Confirmation screen provides the user interface and functions to support Step 16 of the Basic 
Flow. This provides the USER witij confirmation feedback on successftd submission of the reservation. 
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2.4.2 Screen Field Definition 















Office 


Output 


10 


Office Location 


external 

organization 

abbreviated 




Handling for 


Output 


35 


Handling for 


First Name 
+ Last 






Output 


150 


Confirmation 
Statement 


Authorized 

Authorized 
Rate + 
Renter Last 
Name + 

Name 


The screen should provide a statement 
that reads 'You just authorized' + 
Authorized Days + 'days at' + Authorized 
Rate/Policy Limits + '/day for' + Renter 
Last Name + ', ' + Renter First Name 


Don't show me this 
confirmation page 
again 


Check box 


1 


Delete 

confirmation page 




ff checked, the system should not show 
this page again. Instead the system will 
provide the confirmation statement 
(above) in the feedback section of the 
page that the user is returned to (the area 
of the EVERY page reserved for 
feedback, error messages, etc.) 



2.4.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. This 
includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity. 

2.4.3.1 Return to Home Page 

The Return to Home Page screen fimction will allow the USER to return to their home page 
from the reservation confirmation screen. 



2.4.3. 1.1 The Return to Home Page screen fimction is invoked through either a button click or an Enter 
keystroke. 



2.4.3.2 Ctiange Reservation 

The Change Reservation screen fimction will allow the USER to go back into the Quick 
Reservation or Detailed Reservation screen and change any errors. 

2.4.3.2. 1 The Change Reservation screen fimction is invoked by clicking on the feedback hyperlink (e.g.. You 
just authorized 3 days at $29.39/day for Tom Hanks). 
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Find a Rental Location 

1. Find a Rental Location Use Case 

1.1 Application Overview 

The following is a document used to illustrate the process of finding and selecting an alternate rental 
location for a reservation created using ARMS/Web 3.0. The intent for this release of the ARMSAVeb 
application is to reach a much wider audience. This application will target a Multi-Vendor, Multi- 
Segment, and International customer base. 

1.2 Brief Description 

This use case describes the process of finding and selecting an alternate rental location for a reservation 
created in the ARMSAVeb system. The USER will have the ability to select the location search criteria 
they want to use (i.e. phone number or postal code), select the rental company and select to either review 
a list of nearby rental company locations or have the system automatically determine a rental company 
location based on the location search criteria' . This use case provides the mechanism to return rental 
company location information, including address, rental company, and phone number to create a new 
reservation or define a favorite location. 

1.3 Use Case Actors 

The following actors will interact with this use case; 

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to find 
and select a rental location for creating a reservation. This use case refers to a USER in the role 
of a rental administrator. There are various types of customers that the rental administrator 
would represent, which include corporate account holders, car dealerships, insurance companies, 
and others. 

• LOCATOR - The LOCATOR system will determine the nearest rental branch location(s) based 
on the search criteria provided in this use case. 

• ARMS - The ARMS system will receive/send transactions to ARMSAVeb to retrieve the 
information regarding the rental company. 

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this 
system as well. Each company will have the ability to initiate and manage their rentals through 
the use of this application. 

1.4 Pre-Conditions 

• The USER must be logged on to tire ARMSAVeb system. 

• The USER must be creating a reservation or defining a favorite location . 

1.5 Flow of Events 

The Flow of Events includes all steps necessary to select rental location search criteria and retiieve an 
alternate rental branch location(s). 



' The USER will also have the ability to select an alternate location by using the 'Favorite Locations' functionality buUt into the Create Reservation 
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1.5.2 Basic Flow 

The Basic Flow of the Find a Rental Location use case includes all of the required steps for the USER to 
select and input search criteria to find an alternate rental location. The USER will have the ability to view 
detailed information about a rental branch, and select a rental branch location to apply to a new 
reservation. 

1. The USER selects to find an alternate rental location. 

2. The system will prompt the USER for pick up location search criteria (also referred to as 
'where needed' search criteria). This allows the USER to input a telephone number, city, or 
postal code to find a rental branch (or branches) that accepts ARMS/Web reservations in a 
given area^. The USER may also narrow the search by selecting a particular rental company 
along with the location search criteria. The USER will be given the option to view a list of 
rental branch locations matching the search criteria, or to have the ARMS/Web system 
automatically select the rental branch considered the Nearest Match. 

3 . The USER enters the required search criteria. 

4. The USER submits the rental branch location search criteria. 

5 . The system will validate the rental branch location search criteria. 

6. The system will retrieve/return a rental branch location^ (based on USER search/selection 
criteria) to be used by the Create Reservation use case". The rental branch location 
information for the selected branch on the Create Reservation screens will be automatically 
populated with the list below for the current Create Reservation transaction. 

• Branch name* 

• Address 

• Telephone number 

• Rates 

7. The use case is complete. 



^ Rental branch locations have the ability to opt out of accepting ARMS/Web reservations. 

^ The requirements for retrieving a rental branch location can be found on page 5 of this document (Section 1 .7. 1 Requirements for Finding Rental 
Location). 

This use case is also used to defme favorite locations from the 'My Profile' use case. The location will be returned to the 'My Profile' use case 
when the use case is entered from a 'My Profile' screen 
The Branch name has been included for fiiture usability purposes (e.g.. Network Allocation). 





1.5.3 Alternative Flows 



1.5.3. 1 Search Criteria Entered is Invalid 

If the USER enters an invalid Postal Code or Phone Number as location search criteria, an error 
message should be displayed to the USER and the USER should be forced back into Step 2 of the 
Basic Flow. If the error is specific to a data field, the field should be highlighted and the error 
described. 

1.5.3. 1. 1 It will be considered invalid if the 'where needed' search criteria is a 
telephone number and the first three digits (i.e., area code) meet the criteria below: 

• OXX 

• IXX 

• The second and third digits are equal (e.g., 800, 877, 888, etc.) 
Where X equals any digit 0 through 9. 

1.5.3. 1.2 It will be considered invalid if the 'where needed' search criteria is a U.S. or 
Canadian telephone number that does not consist of 10 digits. 

1.5.3.1.3 It will be considered invalid if the 'where needed' search criteria is a U.S. 
postal code that does not consist of 5 or 9 digits. 

1.5.3.1.4 If will be considered invalid if the 'where needed' search criteria is a 
Canadian postal code that does not consist of 6 alphanumeric characters in the format 
AXAXAX where A is an alpha character and X is any digit 0 through 9. 

1.5.3.2 No Rental Branch Locations Found 

If the system cannot determine a rental branch location based on the search criteria entered by 
the USER, Claims Connection will be returned as the location and the use case will end. Please 
refer to section 1.7. 1 Requirements for Finding Rental Location on beginning on page 5 of this 
ftmctional specification for handling of this situation. 

1.5.3.3 View a List of Rental Branch Locations 

If the USER opts to view a list of matching rental locations, the list of matching locations will be 
displayed after Step 5 of the Basic Flow. The USER will have the ability to select one of these 
locations, view more detail about the locations (i.e., maps, hours of operation), or perform 
another location search by entering new search criteria. 

1.5.3.3. 1 If the USER requests additional detail on a specific rental branch in the View 
a List of Rental Branch Locations Alternate Flow, the system should display a screen 
with the selected branch's additional information (Rental Company, Branch name. 
Addresses, telephone/fax numbers. Map to the rental branch location. Hours of 
operation). The USER should eiflier select tiie location from this screen (and be 
returned to Step 6 of tiie Basic Flow), or be retimied to the list of matching locations by 
closing/continuing fi-om this screen. 

1.5.3.3.2 If the USER wishes to perform another rental branch location search in the 
View a List of Rental Branch Locations Alternate Flow, the system should return the 
USER to Step 2 of the Basic Flow. 
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1.5.3.4 Use Case Cancellation 



The USER should be capable of leaving the use case at any time. 



1 .6 Post-Conditions 

• If successfiil, a rental branch location will have been determined and returned to the Create 
Reservation use case. 

• If unsuccessM, the system state remains unchanged. 

1.7 Special Requirements 

The additional requirements of the business use case are included here. These are requirements not 
covered by the flow as they have been described in the sections above. 

1.7.1 Requirements for Finding Rental Location 

Below are the requirements for finding a rental location in the ARMSAVeb system. ARMSAVeb will 
resolve a rental location and pass the location to ARMS for routing (which is a deviation from current 
state handling). These requirements were derived from the current state business requirements for the 
ARMS locator system. 



1. 7. 1. 1 ARI\^SAA/eb will always return a rental branch location for a reservation. For all 
ARMS/Web reservations, ttie following rules for finding a rental location apply: 

1.7.1.1.1 For United States locations, the locator will search a 50-mile radius around 
the renter's phone number or postal code for the closest branch (or branches) that 
accepts ARMS reservations. If the USER selects to review a list of rental branch 
locations, an array of rental branch locations meeting these criteria should be returned. 

1.7.1.1.2 For Canadian locations, the locator will search a 50-mile radius around the 
renter's phone number or postal code for the closest open branch (or branches) that 
accepts ARMS reservations. If no open branches are found, the closest branch (or 
branches) that accepts ARMS reservations should be returned. If the USER selects to 
review a list of rental branch locations, an array of rental branch locations meeting these 
criteria should be retimied. 

1. 7. 1.2 When the rental branch location is determined, the system will retrieve the 
group/branch number, name, shipping address, and telephone number of the 
rental branch location and present them to the USER on the Create Reservation 
screen(s). 



1. 7. 1.3 The system will only display Claims Connection (7680) as the location (with no 
rates) when no location can be found within the 50-mile radius. If Claims 
Connection is displayed, a message should be included to indicate that no rental 
branch location was found within a 50-mile radius of the search criteria, and 
Claims Connection will ensure that the reservation is handled appropriately. 



1.7.2 Maintenance of Source Systems 

This use case requires that several existing AS/400 databases be used to query for information: 

• Locator Database 

• OflBce Information Database 

The use case requires that the information in these databases be kept current and it is assumed that the 
group responsible for maintaining these databases will continue to do so in the fiiture. 

1.8 Extension Points 

None. 




2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 



2.1 Location Search Criteria Screen 

This screen allows the USER to select/input the search criteria they want to use to find a rental location. 



This screen supports Steps 2 and 3 of the Basic Flow. 




Country 


Combo box 


14 


Country 


country code 


This list should consist of United States 
and Canada. This will expand in future 
releases. 

The selection will default to the home 
country of the USER as defmed in the 
USER profile. 




Input Text 


20 


Where Needed 


Where Needed 
Value 




Rental Company 


Combo box 


20 


Rental Company 




This is a list of all the rental companies 
that are participating. 




Postal/Zip Code 


Radio 
Button 


1 


Postal/Zip Code 
Button 


NOT STORED 




Telephone 


Radio 
Button 


1 


Telephone Button 


NOT STORED 


This should be the default radio button 
selectioiL 


City 


Button 


I 


City Radio Button 


NOT STORED 




Automatically 
select the nearest 
office 


Checkbox 


1 


Nearest Match 
Selection 




This checkbox should default to 
checked. 



2.1.3 Screen Function Definition 

This section includes the definitions for all fiinctions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Next 

The Next screen function will allow the USER to submit the information on the Location Search 
Criteria screen and initiate the search for matching locations 

2. 1.3 . 1.1 The Next screen fiinction is launched through either a button click or by 
using the Enter keystroke. 

2. 1.3.1.2 If the information submitted to the ARMSAVeb system is invalid or 
incomplete, this screen function should prompt the USER with an error. The error 
should be specific as to the cause of the failure. All information previously entered 
should remain populated in each field, with the problem field highlighted or otherwise 
identified. 



2.2 Matching Location Screen 

This screen allows the USER to review/select a rental location based on the search criteria entered on the 
Location Search Criteria screen. The screen will present 5 matching records at a time to the USER. The 
USER is given the option of viewing additional detail on a location or entering new search criteria. If 
there are more locations selected by tiie search, the USER will view the next locations (up to 5). This 
screen supports Step 4 of the Basic Flow. , x > n /l^ 

2. 2.1 S ^eenLayoiJt ^'^^^^] \)^ 

(ARMSAVeb 2.0) 



Choose a Locatiort 
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Radio 
Button 


1 


Selector Radio 
Button 




A radio button should be presented for 
every rental branch location record in 
the list 

Only one radio button may be selected. 
The rental branch location that is the 
shortest distance from the search 
criteria entered should be the default. 


Location 


Output 


30 


Rental Location 
Address 


Address Line 


A location should be presented for every 
rental branch location record in the list. 


Rental Company 


Output 


30 


Rental Company 
name 




The name of the rental company that is 
available from the search criteria. 


Miles 


Output 


4 


Miles from Search 
Criteria 




Miles from search criteria should be 
presented for every rental branch 
location record in tiie list. 




. Redesign Pr»[Scr^"Kgtea5g3.0 

FinJ^ental Location _^ 



City 


Output 


18 


Rental Location 
City Name 


City 


A city should be presented for every 
rental branch location record in the list. 


State/Province 


Output 


2 


Rental Location 
State/Province 
Code 


State 


A state/province should be presented for 
every rental branch location record in 
the list. 


Country 


Drop Down 


14 


Country 


NOT STORED 


This list should consist of United States 
and Canada. Hiis will expand in fiiture 
releases. 

The selection will default to the home 
country of the USER as defmed in the 
USER profile. 




Input Text 


12 


Where Needed 
Value 


Where Needed 
Value 




Rental Company 


Combo box 


20 


Rental Company 




This is a list of all the rental companies 
that are participating. 


PostayZip Code 


Button 


1 


Postal/Zip Code 
Button 


NOT STORED 




Telephone 


Radio 
Button 


1 


Telephone Button 


NOT STORED 


This should be the default radio button 
selection. 


City 


Radio 
Button 


1 


City Radio Button 


NOT STORED 




Automatically 
select the nearest 


Checkbox 


1 


Nearest Match 
Selection 


NOT STORED 


This should default to checked. 



2. 2. 3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2. 2. 3. 1 Select this Location 

The Select this Location screen fimction will submit the selected rental branch location in the 
Rental Location Information Container to the ARMSAVeb system, to be used by the Create 
Reservation use case. 



2.2.3.1.1 The Select this Location screen fimction is launched through either a button 
click or by using the Enter keystroke. 

2.2.3.2 Next X of Y 

The Next X of Y screen fimction will allow the USER to view the next five rental locations 
(unless less than five records exist) that match the search criteria. For example, if a total of 8 
locations were returned as part of the search, this screen function would be presented as Next 3 of 
8 



2.2.3.2.1 The Next X of Y screen fimction is launched through a button click. 





2.2.3 .2.3 The Next X of Y screen function should have the X values replaced by the 
number of records remaining to view (up to five) in this search. 

2.2.3.2.4 The Next X of Y screen function should have the Y value replaced by the 
number of total records returned in the search. 

2.2.3.3 Previous 5 of Y 

The Previous 5 of Y screen function will allow the USER to view the previous five rental 
locations that matched the search criteria (and were previously reviewed). 

2.2.3.3. 1 The Previous 5 of Y screen fvmction is launched through a button click. 

2.2.3.3.2 The Previous 5 of Y screen llmction should not be presented on the initial 
search results screen. The Previous 5 of Y screen function should only be available if 
the USER has selected the Next X of Y screen fimction. 

2.2.3.3.3 The Previous 5 of Y screen function should have the Y value replaced by the 
number of total records returned in the search. 

2.2.3.4 Details/Map 

The Details/Map screen fimction allows the USER to review additional information about a 
rental location presented in the list of matching records. Selecting this screen function will open 
the Location Details screen for the rental branch selected. 

2.2.3.4. 1 The Details/Map screen function is launched through a button click. 

2.2.3.4.2 Each rental branch location presented in the list of matching locations should 
have it's own Details/Map button. 

2.2.3.5 Search Again 

The Search Again screen function will allow the USER to submit the Location Search Criteria 
Container information on the Matching Location screen and re-initiate the search for matching 
locations 

2.2.3.5. 1 The Search Again screen fimction is launched through a button click. 

2.2.3.5.2 If the information submitted to the ARMSAVeb system is invalid or 
incomplete, this screen fimction should prompt the USER with an error. The error 
should be specific as to the cause of the failure. All information previously entered 
should remain populated in each field, with the problem field highlighted or otherwise 
identified. 
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Rental Location 

Telephone 

Number 


Telephone 
Number 






Mon 


Output 
Text 




Rental Location 
Start Hours of 
Operation + "-" + 
R 




Rental Location Start Hours of 
Operation +"-" +Rental Location End 
Hours of Operation 

This should be filled with the start and 
end hours of operation for the 'Monday' 
value in the hours of operation array. 


Tue 


Output 
Text 




Rental Location 
Start Hours of 
Operation + "-" + 
R 




Rental Location Start Hours of 
Operation +"-" +Rental Location End 
Hours of Operation 

This should be filled with the start and 
end hours of operation for the 'Tuesday' 
value in the hours of operation array. 


Wed 


Output 
Text 




Rental Location 
Start Hours of 
Operation + "-" + 
R 




Rental Location Start Hours of 
Operation +"-" +Rental Location End 
Hours of Operation 

This should be filled with the start and 
end hours of operation for the 
'Wednesday' value in the hours of 
operation array. 


Hiu 


Output 
Text 




Rental Location 
Start Hours of 
Operation + "-" + 
R 




Rental Location Start Hours of 
Operation +"-" +Rental Location End 
Hours of Operation 

This should be filled with the start and 
end hours of operation for the 
'Thursday' value in the hours of 
operation array. 


Fri 


Output 
Text 




Rental Location 
Start Hours of 

R 




Rental Location Start Hours of 
Operation +"-" +Rental Location End 
Hours of Operation 

This should be filled with the start and 
end hours of operation for the 'Friday' 
value in the hours of operation array. 


Sat 


Output 
Text 




Rental Location 
Start Hours of 
Operation + "-" + 
R 




Rental Location Start Hours of 
Operation +"-" +Rental Location End 
Hours of Operation 

This should be filled with the start and 
end hours of operation for the 
'Saturday' value in the hours of 
operation array. 





This section includes the definitions for all functions that can be performed within the screeiL 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other artor 
activity. 



2. 3. 3. 1 Select this Location 

The Select This Location screen function will submit the selected rental branch location to the 
ARMS/Web system, to be used in other parts of the system. 

2.3.3. 1. 1 Clicking on the Select This Location hyperlink launches the Select this 
Location screen fimction. 

2.3.3.2 Previous 

The Previous screen function will return the USER to the list of locations that was presented 
based on the search criteria that were entered. 

2.3 .3.2. 1 Clicking on the Prev button launches the Previous screen fimction. 

2.3.3.3 Enlarge Map 

The Enlarge Map Screen fimction will retrieve a larger graphic image of the map to the 
location. The larger image will be placed in the same screen location of the Location Details 
screen. 

2.3.3.3.1 Clicking on the Enlarge Map hyperlink launches the Enlarge Map screen 
fimction. 

2.3.3.4 Reduce Map 

The Reduce Map Screen fimction will retrieve a smaller graphic image of the map to the 
location. The smaller image will be placed in ttie same screen location of the Location Details- 
screen. 

2.3.3.4.1 Clicking on the Reduce Map hyperlink launches the Reduce Map screen 
fimction. 

2.3.3.5 Zoom In 

The Zoom In screen fimction will retrieve a more specific (more detailed) graphic image of the 
map to the location. The more specific image will be placed in the same screen location of the 

Location Details screen. 

2.3.3.5.1 Clicking on the Zoom In hyperlink launches the Zoom In screen fimction. 

2.3.3.6 Zoom Out 

The Zoom Out screen fimction will retrieve a more general (less specific) graphic image of the 
map to the location. The more general image will be placed in the same screen location of the 
Location Details screen. 



2.3 .3.6. 1 Clicking on the Zoom Out hyperlink launches the Zoom Out screen function. 





3. Questions and Answers 



Issue Number: 307 



Question: We have heard from the business that the search by name criteria needs to be better. 
Today we search by the &st three letters of the last name. We need to know what criteria is the 
preferred method of search to be done. 

For example: Do we search the entire last name and first name? 

Do we search by the first three letters of the last name and the first letter for the 

first name? 

Do we search by first letter of last name and first letter of first name? 
Need the Business Rule. 



Status: 12 User Review 



Resolution: 4-17-00, Sean O'Donnell - We have spoken to the Rental Redesign folks to find out 
how they are doing last/first name matching, and they are not planning to search by name in the 
new rental system (Telephone Number, Driver's License, and SSN only). They were going to 
have an 'implied wildcard' search by name, but it was taken out in USER review. 



Issue Number: 310 



Question: Do we want the ARMSAVeb to have search available by phone, zip code/postal code, 
city and state. Current state only allows for phone number searches. Do we want to search other 
than phone number 

For example: Do we want to search by phone number or zip code? 

Do we want to search by phone number or zip code or city? 
Need Business Rule 



Status: Closed -Resolved 



Resolution: 3-16-00, Jen Cavanaugh - Talking with Dave Smith.3-22-00,Issue Mtg, Search by 
phone # & zip code only. 

(SHOULD -raE ANSWER BE "SEARCH BY PHONE # AND/OR ZIP CODE?) yes it is and/or 
could be both or one. 




' ARMS I^gagSigq. Project - Rek 
Find a Rental Locatiqp 




Issue Number: 311 



Question: If a daily rental branch is closed, how do we want the system to work? Current state it 
defaults to Claims Connection. We need clarification on how this should work in the 
ARMSAVeb environment. 

3-17-00, Application Team - What do we want to see in the locator, do we want to see just open 
only or all? If no branch is open do we return to Claims Connection? 



Status: Closed - Resolved 



Resolution: 3-16-00, Jen Cavanaugh - Stan's team is going to get w/claims Connection to see 
how this process works after hours. From there we will make some business decisions 
3-20-00, Jennifer Cavanaugh - Stan's team needs to research how ARMS & Retail Res Locator 
works & how they differ. Then we will re-review the question. 

3- 27-00, Sean - 1 talked with Trent Tinsley and Kim Devallance on this topic, which was 
EXTREMELY helpfid. If the adjuster selects a closed branch, the system will route the ticket 
based on the type of service established in the insurance company profile: 

Insurance companies that do NOT have 24-hour service, the reservation will be routed to the 
branch that was selected. The branch will do a callback in the morning when they re-open. 
Insurance companies that have 24-hour service have their reservations re-routed to Claims 
Connection (who will do a callback prior to 9p in any time zone unless otherwise specified by an 
adjuster) if the selected office is not open. This determination is made in the background after 
the adjuster submits the reservation. Claims connection will re-route the reservation to the 
appropriate branch when the customer is contacted. 

Essentially, the way that location selection is handled today can/should be supported in the fiiture 
version of ARMSAVeb (location selection is implied through the F2 - Rates fimction of 
ARMS/400). Please let me know if you have questions with regard to this issue 
update/resolution. 

4- 7-00, Issue Mtg, Sean to check with Carl Jensen to see if the locator pulls back open/closed 
office. Given Sean's update we can close after that, (Don't show to the adjuster that the 
reservation was sent to claims connection) 




Issue Number: 374 



Question: In the Create Reservation functional specification, we have stated that the system will 
pull a location and rates immediately for the USER. The issue arises when we have no location 
to retrieve, in cases that the 'where needed' search criteria is weak or we don't have a branch 
within 50 miles of the search area. In the current state, we show Claims Connection as if it were 
a branch in this situation. This can be somewhat confiising (to see the location on Hanley Road 
in St. Louis if you are in Delaware). In the future state, we think it may be a good idea to notify 
the USER that no location was found, and that the reservation would be handled by Claims 
Connection (see example message below). Any thoughts on this question. . . 
EXAMPLE MESSAGE: 

A rental branch could not be found within 50 miles of 555-5 12-5000. Claims Connection will 
ensure your reservation is handled immediately. Please call 800-CLAIMSCONNECTION for 
additional assistance. 



Status: Pending 

Resolution: 5-8-00, Response firom Sean O'Donnell: Dave liked the idea, and so did BQm. Have 
not heard from Randy on this one, though. Let me know if you need me to follow up, otherwise 
this will be written in to the specification for Finding a rental location. 
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Send Message 

Send Message Use Case 
Brief Description 

This use case describes the process of capturing messages and diary notes associated with a rental 
reservation/authorization. The USER can elect to either have the message sent to the Enterprise rental 
branch location responsible for the reservation/authorization (MESSAGE in this document), or to store the 
note in the ARMS Web system without sending the message to Enterprise (DIARY NOTE in this 
document). All MESSAGES and DIARY NOTES captured must be related to a specific 
reservation/authorization. 

NOTE: This is a sub-use case that must be accessed from another use case. For example, a USER may 
send a message while creating a reservation, maintaining an authorization, or completing an extension. 



Use Case Actors 

The following actors will interact with this use case, 
case: 



All actors are referred to as USER throughout this use 



• ADJUSTER - The ADJUSTER will use this use case to enter and send a message about a 
reservation/authorization to the rental branch location that is responsible for the 
reservation/authorization. The ADJUSTER may also use this use case to capture diary notes. 

• PROCESSOR - The PROCESSOR will use this use case to enter and send a message about a 
reservation/authorization to either the rental branch location or the ADJUSTER that is responsible 
for the reservation/authorization. 

• ENTERPRISE ADMINISTRATOR - The ENTERPRISE ADMINISTRATOR will use this use 
case to send a message on a specific transaction to notify the rental branch location or other user 
of issues/complications in transmission of the transaction. 

Pre-Conditions 

• The USER must be signed-on to the ARMS Web system. 

• The USER must have selected an authorization that is in a state that allows MESSAGES or DIARY 
NOTES. 



1.4 Flow of Events 

The Flow of Events includes all steps necessary to enter MESSAGES and DIARY NOTES. 




The Basic Flow of the Send Message use case includes all of the required steps for the USER to enter a 
MESSAGE or DIARY NOTE. 

1 . The USER will indicate that they want to send a MESSAGE for a reservation/authorization. 

2. The system will display a screen that will capture the message/note text. 

3 . The USER will enter the message/note text. 

4. The USER returns to the parent use case, and the system stores the text message to be sent at a 
later time (see Special Requirements). 

5. This ends this use case. 

14.3 Alternative Flows 

1.4.3.1 Send Diary Note Only 

The USER will have the ability to indicate that the MESSAGE text should be stored as a DIARY 
NOTE only in Step 3 of the Basic Flow. This text should not be sent to the Enterprise rental 
branch location handling the reservation/ticket. 





1.4.3.2 Use Case Cancellation 

The USER should be capable of leaving the use case at any time. 



1.5 Post-Conditions 

• If successful, the message/note text will be updated in the ARMS Web database. MESSAGES 
requested to be sent to the rental branch location are sent to ARMS. 

• If unsuccessful, the system state remains unchanged. 



1.6 Special Requirements 

1.6.1 Submit Message Responsibilities 

The parent use case that accessed this function will have the responsibility of submitting the text message 
to the ARMS Web database. Based on USER input, the parent use case must complete the following 
action: 

• If the USER chose to have the text sent to the rental branch location as a MESSAGE, the text 
will be written to the ARMS Web database and the MESSAGE will be sent to ARMS. 
ARMS will forward the text to ECARS for distribution to the appropriate rental branch. 

• If the USER chose to save the text as a DIARY NOTE, the text will be written to the ARMS 
Web database as a DIARY NOTE only. 

1.7 Extension Points 

None. 
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Screen Design 

As noted in the Send Message Use Case, the Send Message function will be available on multiple screens 
throughout the system (e.g., Create Reservation, Extend Rental, Change Authorization). This section 
provides functional description of the screen container that is used on the multiple screens to support the 
Send Message use case. 



Screen Container 



2.1.1 Screen Layout' — ^\<jJ-nL, t .'^ 




The area of the screen under consideration is the container beginning with the Notebook heading^^^^ 



_ HtQ j|nt^pri^ejwtalJU ;; anc^^ This is an example of how tl 

message container might look on any given screen. 



2. 1.2 Message Screen Container 



to Enterprise 



b ut will NOT be f orwarded to ARMS. 



Text eaetered ir 



Note to Self Only 



tojheEnterprise rental branch location. 
Text entered into this field will be stored 
in the ARMS Web database but will not 
be sent to the Enterprise rental branch 



' This is the screen layout for the Create Reservtaion screen. The Mess^e screen container is part of this screen, and is shown here for 
illustrative purposes only. 




Issue Number: 341 



Question: Current state ARMS400 allows user to enter maximum of four lines of fifty characters. 
Current state ARMS has program limitation of ten lines of fifty characters. ARMS Web will be 
limited by current state ARMS. Should that be the planned maximum for ARMS Web or ??? One 
idea would be to have the number of lines/characters profiled. Then the size of the message box 
that is displayed to the user would be limited by this profiled amount 



Status: Closed - Resolved 



Resolution: 3-30-00, Kim DeVallance - 1 think ten lines of fifty characters to be entered by any 
user at a time is more than enough. I don't really for see the need to profile this by company 



Issue Number: 342 



Question: Current state allows message to be sent on unauthorized requests only if they have not 
been assigned to an adjuster. How should future state work? If we allow messages on assigned 
unauthorized requests, we must keep in mind that we are defaulting the Direct-Bill To percent at 
100% on all auth. screens. When the adjuster submits the message, they MAY be unintentionally 
authorizing the request. 



Status: Closed - Resolved 



Resolution: 3-30-00, Kim DeVallance - Kim: we should never send an authorization to the 
branch if all the adjuster did was key in a message. The message will either appear in ECARS 
under res notes or callback notes, but should never appear to the branch as an authorization. We 
not only need to give the adjuster the ability to send a message, but they should be able to change 
info (such as claim number, claim type, etc) before assigning the request to the adjuster, thereby 
enabling the adjuster to see the correct info when authorizing or denying a DB. We hear this 
request a lot from our customers. 




Ent^rpns^Jlent-^A::^ 
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Additional Charges 

Additional Charges Use Case 
Brief Description 

The Additional Charges use case will allow the USER to view, add, or modify/remove any additional 
charges that may be associated with a rental authorization. Additional Charges such as Collision/Damage 
Waiver (CDW), Mileage Charge, or any other rental related charge could be authorized by a USER 
through this function. 

Use Case Actors 

The following actors will interact with this use case: 

• ADJUSTER - The ADJUSTER will use diis use case to view, add, or modify any additional charges 
that are associated with a rental authorization. 

Pre-Conditions 

• The USER must be signed-on to the ARMS Web system. 

• The USER must have a reservation or open ticket selected (active). 

Flow of Events 

The Flow of Events will include the necessary steps to view, add and modify additional charges associated 
with a rental authorization. 




14.2 Basic Flow 

The Basic Flow of the Additional Charges use case includes all of the required steps to view, add, or 
modify Additional Charges as part of an authorization. 

1 . The USER will select Additional Charges for the active reservation or open ticket. 

2. The system will prompt the USER to add, modify or remove Additional Charges. 

3 . The USER will view, add, or modify Additional Charges that will be authorized. 

4. The USER will submit the Additional Charges to the system. 

5. The system will validate the Additional Charges entered by the USER. 





6. The system will return the USER to the active reservation or open ticket and populate Additional 
Charges'. 



7. This ends this use case. 
1.4.3 Alternative Flows 

1.4.3.1 Additional Charges Invalid 

If the Additional Charges entered by the USER are invalid, the system should present an error 
message to die USER and force the USER back into Step 2 of the Basic Flow. The system will 
declare additional charges invalid in the following circumstances: 

1.4.3.1 .1 It will be considered invalid if the additional charge type is 'Dollars per Day' 
or 'Dollars per Rental' and the additional charge value entered is greater than $999.99. 

1 .4.3. 1 .2 It will be considered invalid if the additional charge type is 'Dollars per Day' 
or 'Dollars per Rental' and the additional charge value entered is less than $0. 

1 .4.3 . 1 .3 It will be considered invalid if die additional charge type is 'Percentage of 
Rental' and the additional charge value entered is greater than 100%. 

1 .4.3. 1 .4 It will be considered invalid if the additional charge type is 'Percentage of 
Rental' and the additional charge value entered is less than 0%. 



1.5 Post-Conditions 

• If successful, the Additional Charges that were added or modified will be returned to the active 
reservation or open ticket. 

• If unsuccessfiil, no Additional Charges will be added to the active reservation or open ticket. 



1.6 Special Requirements 

The additional requirements of the business use case are included here. These are requirements not covered 
by the flow as they have been described in the sections above. 

1.6.1 Submit Additional Charges Responsibilities 

The parent use case that accessed this function will have the responsibility of submitting the additional 
charges to the ARMS Web database. Any additional charges returned to a parent use case should be 
reflected on die screen within that use case. For example, if additional charges were being added as part of 
the Create Reservation process, the Create Reservation screens should have some indication that additional 
charges have been added. 



' The Additional Charges should not be submitted to the ARMS Web database until the USER submits the changes on the active reservation or 
open ticket. 




1.6.2 Additional Charges Descriptions 

Below are the current additional charge descriptions used in the ARMS/400 system in the current state: 



DAMAGE WAIVER 
PAI 

MILEAGE CHARGE 

HOURLY 

DAILY 

WEEKLY 

MONTHLY 



SPECIAL 
DROP CHARGE 
MISC CHARGES 
SLP 

UNDERAGE DRIVER 
BABY CAR SEAT 
SKI RACK 



1.7 Extension Points 

None. 
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Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

Additional Charges 

This screen will allow the user to view, add, modify or 
reservation/authorization. 



additional charges associated with a 



2. 1. 1 Screen Layoul^j^^^^-^-ll:^ 




^ 'tD n'X^ 

2.1.2 Screen Field Definition 















CDW (Collision 
Damage Waiver) 


Check Box 




CDW (Collision 
Damage Waiver) 






PAI (Personal 

Accident 

Insurance) 


Check Box 


1 


PAI (Personal 
Accident Insurance) 






Underage Driver 


Check Box 


1 


Underage Driver 






Drop Charge 


Check Box 


1 


Drop Charge 






Mileage Charge 


Check Box 


1 


Mileage Charge 






Misc. Charge 


Check Box 


1 


Misc. Charge 
Check Box 






Create Charge 
Type 


Text Box 


15 


Additional Charge 
Description 




A description of the additional 
surcharge to be authorized. 



Additional Charge 
Type 



A Type combo box should be 
included for every check box 



Values include: Dollars per 
Day (DEFAULT); Dollars per 
Rental; Percentage of Rental 



Screen Function Definition 

This section includes the definitions for all fiuictions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2. 1.3. 1 Create More Surcharges 

The Create More Surcharges screen function will allow the USER to select the hyperlink and have 
an additional Misc. Charge line added to the screen. For example, the Screen Layout above shows 
only one Misc. Charge box. If a USER were to click on the Create More Surcharges hyperlink, 
the screen would refresh and provide the user with two Misc. Charges boxes. The USER is not 
limited to the number of Misc. Charge boxes that can be added. 



2.1.3.1.1 The Create More Surcharges screen function is invoked through clicking a 
hyperlink. 

2.1.3.2 Process 

The Process screen function allows the USER to save the additional charges that are being 
authorized and return to the active reservation or open ticket. The active reservation or open 
ticket will reflect that additional charges have been added. 



2. 1 .3 .2. 1 The Process screen function is invoked through a button click or through an 
Enter keystroke. 

2.13.3 Previous 

The Previous screen fiinction will allow the USER to return to the active reservation or 
open ticket without saving the updates to additional charges. 



2 . 1 .3 .3 . 1 The Previous screen function is invoked through a button click. 





3. Questions and Answers 

None. 
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Additional Charges / 

1 . Additional Charges Use Case 

1 .1 Brief Description 

The Additional Charges use case will allow the USER to view, add, or modify/remove any additional 
charges that may be associated with a rental authorization. Additional (^arges such as Collision/Damage 
Waiver (CDW), Mileage Charge, or any other rental related charge coxAA be authorized by a USER 
through this function. 

1.2 Use Case Actors / 

The following actors will interact with this use case: / 

• ADJUSTER - The ADJUSTER will use this use case to ^iew, add, or modify any additional charges 
that are associated with a rental authorization. / 

1.3 Pre-Conditions 

• The USER must be signed-on to the ARMS Web system. 

• The USER must have a reservation or open ticket /elected (active). 

/ 

1.4 Flow of Events 

The Flow of Events will include the necessary steps to view, add and modify additional charges associated 
with a rental authorization. 
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1.4.1 Activity Diagram 

Additional Ctiarges Activity Diagram 




USER 
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Tha.system will return the USER to the active reservation or open ticket and populate Additional 
Charges'. 

7. This ends this use case. 
7.4.3 Alternative Flows 

1.4.3. 1 Additional Charges Invalid 
If the Additional Charges entered by die USER are invalid, die system should present j(n error 
message to the USER and force the USER back into Step 2 of the Basic Flow. The^stem will 
declare additional charges invalid in the following circumstances: 

1.4.3. 1.1 It will be considered invalid if the additional charge type is /Dollars per Day' 
or 'Dollars per Rental' and the additional charge value entered is greater than $999.99. 

1 .4.3 . 1 .2 It will be considered invalid if the additional charge type js 'Dollars per Day ' 
or 'Dollars per Rental' and the additional charge value entered is l4s than $0. 

1 .4.3. 1 .3 It will be ciqnsidered invalid if the additional charge ty^e is 'Percentage of 
Rental' and the additional charge value entered is greater than 100%. 

1 .4.3 . 1 .4 It will be considered invalid if the additional charge 
Rental' and the additional charge value entered is less than 0% 



1.5 Post-Conditions 

• If successful, the Additional Charges that were added or modified v^W be returned to the active 
reservation or open ticket. / 

• If unsuccessful, no Additional Charges will be added to the activ^' reservation or open ticket. 

1.6 Special Requirements / 

The additional requirements of die business use case are inclnded here. These are requirements not covered 
by the flow as they have been described in the sections abov^'^ 

1.6.1 Submit Additional Charges Responsibilities 
The parent use case diat accessed this function will have/6ie respikisibility of submitting the additional 
charges to the ARMS Web database. Any additional charges returted to a parent use case should be 
reflected on the screen within diat use case. For example, if additioft^ charges were being added as part of 
the Create Reservation process, the Create Reservatibn screens should^have some indication that additional 
charges have been added. 



' The Additional Charges should not be submitt^ the ARMS Web database until the USER submits the clnge 
open ticket. 
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1.6.2 Additional Charges Descriptions / 

Below are the current additional charge descriptions used in the ARMS/400 system in/the current state: 

V DAMAGE WAIVER • SPECIAL / 

• , PAI • DROP CHARGE 

• MILEAGE CHARGE • MISCCHfRGES 

• HOURLY . SLP / 

• DAILY « UNDERAGE DRIVER 

• WEEKLY . BABY CAR SEAT 

• MO>iTHLY . SKliACK 



Extension Points 

None. 



/ 
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Screen Design 

A definitiVi of the screen layout(s), s 
flows identified above. More than one S( 

Additional C 

This screen will\llow the user to v 
reservation/authorli 



1 data fields, and screen functions that are used to implement the 
een may be used to implement support for the user case flow. 



/, add, modify or remove additional charges assoptated with a 



2.1.1 Screen LaVQut 



.ayQut 



Additional Charges 

Atid. eilft surcfiarges to 'he Auihorszation fof Tom Hanks Cfaim Ko. 123<5i 
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Amount \^ 


Text Box 


6 


Additional Charge 




An Amount text box should be 
inoJuded for every check box 
o/ the screen. 


Type 


ComboBox 

\ 


20 


Additional Charge 
Type 




A Type combo box should be 
1 included for every check box 
on the screen. 

Values include: Dollars per 
Day (DEFAULT); Dollars per 
Rental; Percentage of Rental 



2.1.3 Screen Function Definition 

This section includes the definitions for all functions that cmI be performed within the screen. 
This includes ojjerations invoked by button clicks, specific/shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Create More Surcharges / 

The Create More Surcharges screen function will a|low the USER to select the hyperlink and have 
an additional Misc. Charge line added to the scree/. For example, the Screen Layout above shows 
only one Misc. Charge b(jx. If a USER were to click on the Create More Surcharges hyperlink, 
the screen would refresh and provide the user v^ith two Misc. Charges boxes. The USER is not 
limited to the number of Misc. Charge boxes ^at can be added. 

2.1.3.1.1 The Create M^re Surcharges screen function is invoked through clicking a 
hyperlink. \ / 

2.1.3.2 Process \ j 

The Process screen function allows the'WSER to save the additional charges that are being 
authorized and return to the active resepation or open ticket The active reservation or open 
ticket will reflect that additional charges K^ve been added. 



2.1.3.2.1 The Process 
Enter keystroke. 



fiinctidn is invoked through a button click or through an 



2.1.3.3 Previous 



The Previous screen fiinction will allow thMJSER to return to the active reservation o 
open ticket without s4ving the updates to additional charges. 

through a button click. 
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View Car Class Use Case 
Brief Description 

This use case will allow the USER to view examples of automobiles that are part of each Enterprise Car 
Class. The USER will have the ability to select a car class and have the rate for the car class apply to the 
reservation/authorization. 

Use Case Actors 

The following actors will interact with this use case: 

• ADJUSTER - The ADJUSTER will use this use case to view and/or select the car class that will 
apply to a reservation. 

Pre-Conditions 

• The USER must be signed-on to the ARMS Web system. 

• The USER must have a reservation or open ticket selected. 

Flow of Events 

The Flow of Events will include the necessary steps to view and/or select the car class to apply to a rental 
reservation. 



1.4.1 Activity Diagram yJiJL (^i gcjr-«_ tr .""^ 

\ View Car Class Activity Diagram 
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Basic Flow 

The Basic Flow of the View Car Class use case includes all of the required steps to view and/or 
select a car class for a rental reservation. If a car class is selected, it will be used to populate rate 
information on a rental authorization. 

1 . The USER will select View Car Class from the active reservation or open ticket. 

2 The system will display a car class detail screen. If the USER had previously selected a car 

class (for example, on the Create Reservation screen), the car class selected will be displayed. 

If no car class has been selected, the system will display the Standard car class. 

3 . The USER will select the car class to apply to the reservation or open ticket. 

4. The system will return the USER to the active reservation or open ticket and populate car 
class information based on the car class selected. 

5. This ends this use case. 



1.4.3 Alternative Flows 

1.4.3.1 Select Alternate Car Class 

From Step 2 of the Basic Flow, the USER will have the ability to view an alternate car class. The 
car classes that will be available to view include: 

■ Economy 
» Compact 

■ Intermediate 

■ Standard 

■ Full Size 

■ Premium 

If the USER selects an alternate car class, the system will refresh and present the details of the 
new car class. 

14.3.2 Populate Car Class Rates 

If a rental branch location has already been selected prior to entering this use case, the selection of 
a car class will populate the rates that apply to the selected car class on the active reservation or 
open ticket This alternate flow returns the USER to Step 4 of the Basic Flow. 



1.5 Post-Conditions 

• If successful, the selected Car Class will be returned to the active reservation or open ticket. 

• If unsuccessfiil, the system state is unchanged. 
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1 6 Special Requirements 

■ The additional requirements of the business use case are included here. These are requirements not covered 
by the flow as they have been described in the sections above. 

1 6 1 Modify Car Class Selection Results 

The USER may change the results of this use case as part of the active reservation or open ticket. 

1.7 Extension Points 

None. 
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Screen Design 

A definition of the screen layout(s), screen data fields, and screen ftinctions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 



iew detailed information al 
iss to ^ply to a rental rese 



Car Class DetanScreen__^ _ 

This screenAJ&ow the USER to view detailed information about Enterprise car classes. The USER will 
also have the ability to select a car class to ^ply t( 

2.1.1 Screen Layout - C<^^ 



rental reservation / authorization. 



2.1.2 Car Class Details 













Output 


20 


Car Class Name 




This should be the name of 
the currently selected car class 


(Person Image) 


Output 


2 


Car Class Person 
Capacity 




This should provide the 
average person capacity of the 
selected car class. 


(Luggage 
Image) 


Output 


2 


Car Class Luggage 
Capacity 




This should provide the 
average luggage capacity of 
the selected car class 




Hidden 


255 


Car Class Image Source 




This should provide a picture 
of an example car within the 
selected car class. 




Output 


120 


Car Class Detail 
Description 




This should provide a 
description of the selected car 
class. 


Economy 


Output 




Economy Car Class 




This should be a hyperlink to 
the Economy car class detail. 
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Compact Car Class 




This should be a hyperlink to 


Compact 


Output 






the Compact car class detail. 


Intermediate 


Output 




Intermediate Car Class 




This should be a hyperlink to 
the Intermediate car class 
detail. 


Standard 


Output 




Standard Car Class 




This should be a hyperlink to 
the Standard car class detail. 


Full Size 


Output 




Full Size Car Class 




This should be a hyperlink to 
the Full Size car class detail. 


Premium 


Output 




Premium Car Class 




This should be a hyperlink to 
the Premium car class detail. 



2.13 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Select This Car Class 

The Continue screen function will allow the USER to select the car class to apply to a 
reservation. 

2.1.3.1.1 The Continue screen function is invoked through either a button click or 
through an Enter keystroke. 

2.7.3.2 Previous 

The Previous screen function allows the USER to return to the previous screen. 



2.1.3.2.1 The Previous screen function is invoked through a button click. 
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3. Questions and Answers 

None. 
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1. Assign a Request Use Case 

1.1 Brief Description 

This use case describes the process of how a USER will review unassigned authorization request and assign 
them to an adjuster for further handling. 

1 .2 Use Case Actors 

The following actors will interact with this use case: 

• CLAIMS PROCESSOR - The CLAIMS PROCESSOR is a USER who can perform this use case to 
assign a request for further handling. 

• ADJUSTER - The ADJUSTER is a USER who can receive the assigned request for further handling. 

1.3 Pre-Conditions 

• The USER must be signed-on to the ARMS Web system. 

• The USER should be authorized to assign a request. 

• If there are unassigned requests present, the USER has selected the link from the Review List Action 
Items Use Case to enter this use case. 



1.4 Flow of Events 

The Flow of Events will include the necessary steps to make changes and updates to "Assign an Action 
Item". 



1 



1.4.2 Basic Flow 

1 . The USER selects the unassigned authorizations Unk. 

2. The system retrieves all unassigned request summaries. 

3 . The system retrieves all OFFICE IDs w^ithin ARMS Web. 

4. The system retrieves all USER IDs within the OFFICE. 

5. The system displays the unassigned authorization summaries with the offices and adjusters. 

6. The USER selects an adjuster to assign to the request. 

7 . The system will update the ARMS Web database. 

8. This ends the use case. 

1.4.3 Alternative Flows 

1.4.3. 1 Cancel Use Case 

The USER should be capable of leaving the use case at any point prior to assigning the reservation 
information to an ADJUSTER. 

14.3.2 Modify a Request 

Before step 6 of the basic flow, the USER should be able to make changes to the authorization. 
1.4.3.3 Select a different office 

Before step 6 of the basic flow, the USER should be able to select a different office for this 
authorization request. If a different office has been selected, the user cannot assign the file to a 
new adjuster. The new office must now assign the file. 

Post-Conditions 

If the use case is successful, the system will change the request type from an unassigned authorization 
request to direct bill. If the user has authority to authorize this request, the system will change the request to 
Authorized status and assign the adjuster picked in Step 5 of the basic flow. 

If the use case is unsuccessful, the system state will remain unchanged. 

Special Requirements 

None 

Extension Points 

1.7.1 MA-04 Send Message 

The Send Message function will be used to allow the user to capture messages and diary notes 
associated with a rental reservation/authorization. The USER can elect to have the message sent to 
the Enterprise rental branch location responsible for the reservation/authorization. The USER may 
also send a message without assigning the file to an adjuster/office. All MESSAGES and DIARY 
NOTES captured must be related to a specific reservation/authorization. 

1.7.2 MA-10 Authorize a Regues 

The ADJUSTER may decide to enter into the full detail screen of the unassigned request, which 
would invoke the Authorize a Request case. 

17.3 MA-17 Cancel Authorization 

At any point prior to assigning the file to an ADJUSTER, the USER should have the ability to 
cancel the authorization. If the authorization is cancelled, the ADJUSTER will be prompted to 
select a cancellation reason code from a drop down list along with having the option to enter 
additional comments. 



Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

Action Items - Unassigned 

This screen will allow the USER assign action items to a claims office or an adjuster or the USER may 
cancel an item. The USER may also change specified information in the Customer File through this screen 

2.1.1 Screen Layout- Action Items - Unassigned 5.©^ ^^5^^^ ^"^^ 



Welcome to tho 

Automated Rental Management SysteT. 



Claims Office: 001 
oice for Crystal, Billy - Total Amount $536.13 



Handling for Yourself 



Wel3g^ Andrew 

28445 Main Ave 
Chicago. ILB0622 
555-555-1212 



WLl, RE QUEST 

Number:|75'1589877 



Vehicle Condltlon:| Select a Loss Type slj} 
Claim Type:) Select a Claim Type \^ 
Date of Loss j January ^T^jl «jj20ni!;»Jr 
Note to Enterpnse:] 



O Assign Atijuster | Unassigned 



Smith, Joe 

28445 Main Ave 
Chicago, IL 60622 
555-555-1212 



!r:j754589877 
Vehicle Condition:j Select a Loss Type jpl 
Claim Type:] Select a Claim Type 
Date of Loss | January 2h M\^°°'^ 
Note to Enterpnse;] ~_ ^ 



e 1 001 



1 Unassigned 



v_ 





2.7.2 Action Items - Unassigned 

Claims Office: 



Output 



Office Id 



external 
organization 
abbreviated name 



Handling for 
Adjuster's Name 



First Name + Last 



30 Renter's Name 



First Name + Last 



This should be a link. The USER 
should be able to get to the authorize 
from this screen field 



Renter's Address 



Zip Code 



Renter's Home Phone 



Renters Night 
Phone + Renters 
Night Phone 
Extensin 



If these fields are populated, add a label 
to the screen to differentiate between 
Home Phone and Work Phone 



Renter's Work Phone 



Day Phone + 
Renters Day 
Phone Extension 



If these fields are populated, add a label 
to the screen to differentiate between 
Home Phone and Work Phone 



Insurance Claim 
Number 



Vehicle 
Condition 



loss type 
description 



claim type 
description 



Note to 
Enterprise 



external 
organization 
abbreviated n; 



First Name + 



Lists only those adjusters the USER has 
authority to assign 



Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. This 
includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity. 



2.1.3.1 «Previous 

When clicked, the USER will be taken back to the previous screen. 



2.13.2 Process 

When clicked, the USER will be taken to the next item in the action item list or a detail of the 
completed action items. This button ends the use case 



2.1.3.3 Cancel 

When clicked, the USER will be allowed to cancel the authorization. If this occurs, the rental 
becomes unauthorized and the rental is no longer the responsibility of the insurance company. 




/ Issue Date: \mom 



2.1.3.4 Last Action Message 

After each action item in the USER'S list has been completed, upon arriving at the next item there 
will be a confirmation message at the top of the screen. This message will be a hyperlink 
describing the last completed action. If the USER clicks on this link, the system will open the 
customer file, which will reflect all of the current information for the rental. The USER is then free 
to make additional changes or to simply view the file. 
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4. Data Fields 

4.1 Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 Address Line 



Entity 


ARM: Renter Detail 


Column Name 


RKADLl 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 




4.12 City 


Entity 


ARM: Renter Detail 


Column Name 


RKCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.13 claim type code 


Entity 


AUTHORIZATION EXTENSION 


Column Name 


dm typ cde 


Label Name 


claim type code: 


System Name 


CLMTYPCDE 


Data Type 


DEC(3,0) 


Attribute Definition 


The claim type code defines the different Authorization claim types. For 
example: Insured, Claimant, Uninsured Motorist, etc. 


4.1.4 claim type description 


Entity 


CLAIM TYPE 


Column Name 


clmtypdsc 


Label Name 


claim type description: 


System Name 


CLMTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The claim type description is a lexical definition of the claim type code 
which defines the different Authorization claim types. For example: 
Insured, Claimant, Uninsured Motorist, etc. 
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4.1.5 company identifier 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


cmpy id 


Label Name 


company identifier: 


System Name 


CMPYID 


Data Type 


DEC(11,0) 


Attribute Definition 


Business Party Identifier is a surrogate key assigned to each unique 
occurrence of an Individual, External Organization, and Internal 
Organization (Business Party). 


4.1.6 DATE OF LOSS 


Entity 


A4 Cross Reference 


Column Name 


X4LSDT 


Label Name 


DATE OF LOSS 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.17 Day Phone 


Entity 


ARM: Renter Detail 


Column Name 


RKDYPH 


Label Name 


Day Phone 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4.1.8 external orpanization abbreviated name 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(10) 


Attribute Definition 


External Organization Abbreviated Name is a shortened text based label 
associated with an organization outside of Enterprise. This name is 
sometimes used for accounting purposes. 



4.1.9 external orQanization identifier 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


e 0 id 


Label Name 


external organization identifier 


System Name 


EOID 


Data Type 


DEC(11,0) 


Attribute Definition 


The external organization identifier is a surrogate key assigned to each 
unique occurrence of an External Organization. Examples: body shops, 
vehicle manufacturers, insurance companies, leasing accounts, credit unions, 
dealerships, or government agencie 
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4.1.10 First Name 



Entity 


ARM: Adjuster Master 


Column Name 


ALFSNM 




Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 





4.1.11 First Name 



Entity 


ARM: Renter Detail 


Column Name 


RKFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 





4.1.12 iiandled by adjustor code 



Entity 


ACTION ITEM 


Column Name 


handlbyadj rede 


Label Name 


Adjustor Code 


System Name 


HNDADJRCDE 


Data Type 


CHAR(10) 


Attribute Definition 


The handled by adjustor code is the adjustor code of the administrator or 
adjuster's who is handling the action item. 



4.1.13 handled by company identifier 



Entity 


ACTION ITEM 


Column Name 


handlbycmpyid 


Label Name 


ARMS Profile ID 


System Name 


HNDCMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The handled by company identifier is the company identifier of the 
administrator or adjuster's who is handling the action item. 



4.1^4 tiandiing for adjustor code 



Entity 


AUTHORIZATION ACTIVITY LOG 


Column Name 


handl for adtr cde 


Label Name 


handling for adjustor code: 


System Name 


HNDADJRCDE 


Data Type 


CHAR(10) 


Attribute Definition 


The handling for adjustor coder is the adjustor code of an adjustor/user who 
is handling authorization activities for another adjustor/user in the ARMS 
Web application. 
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4.1.15 handling for company identifier 



Entity 


AUTHORIZATION ACTIVITY LOG 


Column Name 


hand! for cmpy id 


Label Name 


handling for company identifier: 


System Name 


HNDCMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The handling for company identifier is the company identifier used to 
uniquely identify an adjustor/user who is handling authorization activities 
for another adjustor/user in the ARMS Web application. 



4.1.16 Insurance Claim Number 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.1.17 Last Name 



Entity 


ARM: Adjustor Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.1.18 Last Name 



Entity 


ARM: Renter Detail 


Column Name 


RKLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.1.19 loss type description 



Entity 


LOSS TYPE 


Column Name 


loss_typ_dsc 


Label Name 


loss type description: 


System Name 


LOSSTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The loss type description is a lexical definition of the loss type code which , 
defines the different loss categories when an Insurance Company authorizes 
a Rental. For example: Theft, Drivable, Repairable, Non-drivable, Non- 
repairable, Totaled. 
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4.1.20 NOTE 


Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NENOTE 


Label Name 


NOTE 


System Name 




Data Type 


CHAR(50) 


Attribute Definition 





4.1.21 Renters Day Phone Extension 



Entity 


ARM: Renter Detail 


Column Name 


RKDYEX 


Label Name 


Renters Day Phone Extension 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 





4.1.22 Renters Night Phone 



Entity 


ARM: Renter Detail 


Column Name 


RKNTPH 


Label Name 


Renters Night Phone 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 





4.7.23 Renters Night Phone Extensin 



Entity 


ARM: Renter Detail 


Column Name 


RKNTEX 


Label Name 


Renters Night Phone Extensin 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 





4.1.24 State 



Entity 


ARM: Renter Detail 


Column Name 


RKSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 





4.1.25 Zip Code 



Entity 


ARM: Renter Detail 


Column Name 


RKZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 
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Questions and Answers 



Issue Number: 345 



Question: Do we force the user to view the Rental Detail in order to change the unassigned 
adjuster to an adjuster who is authorized to handle? 



Status: Closed - Resolved 



Resolution: 4-12-00, Randy Haselhorst, we don't want to force them to look at the detail to assign 
a rental request to another user. They primarily look for claim number, claim type, renter name 
and possibly date of loss. If you can make the option you've described intuitive, that may work, 
but it doesn't sound that way to me. 

4-12-00, Kim DeVallance, NO - This is a great feature, but I don't know if it is necessary. Some 
companies use this feature, while others wait for the phone call to authorize. 



Issue Number: 346 



Question: Should you be allowed to decline, authorize or extend an unassigned rental. 



Status: Closed - Resolved 



Resolution: 4-12-00, Randy Haselhorst - you can't "extend" until you've authorized. Decline 
could be an option, but we should probably think about that more to determine if we should. 
Current state does not have this but I have heard people ask for it. As far as authorizing, that 
again may be a good idea. I'd like to see Kim and Dave's ideas. 

4-12-00, Kim DeVallance - Yes, we have heard this many, many times that will assigning a rental, 
the user should have the ability to do all these things (as long as the user has the proper authority) 
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Issue Number: 361 

Question: Can we pass along an unassigned to another office? 
Status: Pending 

Resolution: Yes, If the request is an unassigned status, the USER can transfer it to another office. 



Issue Number: 378 

Question: Can we Exit the use case after Sending a Message and leave the request unassigned? 
Iteration 2 quesiton. 

Status: Closed - Resolved 

Resolution: 6-23-00 Per Brian Weingart, - yes, after sending a message on an unassigned 
request, if we didn't assign an adjuster, it is still unassigned. 



Issue Number: 413 

Question: 6-23-00, Only one person can handle un-assigns - which is set up in the profile? Or 
can a multiple # of people handle the un-assigns? Does the Handling for drop down box allow for 
the selection of unassigned? How do we handle record locking? Per Jennifer, Sean is working 
on this issue. 

Status: Pending 



Resolution: 
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Issue Number: 414 

Question: 6-23-00, If I select Unassigned from the action item list and only one exists do I go 
straight to the detail? Per Jennifer - Sean is working on this issue 

Status: Pending 

Resolution: 



Issue Number: 415 

Question: 6-23-00, If I select Unassigned from the action item list and multiple exists I go 
straight to the detail. I go to a screen, which looks like action items, but list all of the unassigned. 
Per Jennifer - Sean is working on this issue. 

Status: Pending 



Resolution: 
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Authorize a Request 



1 . Authorize Request Use Case 

1.1 Brief Description 

This use case describes how a USER authorizes a direct bill request. 

1.2 Use Case Actors 

The following actors will interact with this use case: 

• ADJUSTER - The USER will use this system to authorize a direct bill request. 

1.3 Pre-Conditions 



• The USER must be logged into the ARMS Web system. 

• The USER must have the authority to authorize a request. 

• At least one outstanding unauthorized direct bill request must be assigned that the USER may 
handle. 

• The USER must have selected an Unauthorized Direct Bill Request from the Review Action Items 
Screen or from the Search Results page. 



1.4 Flow of Events 

The Flow of Events will include the necessary steps to make changes and updates to "Authorize Request" 
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1.4.2 Basic Flow 

1 . The USER selects an outstanding direct bill to authorize. 

2. The system displays the Customer file. 

3. The USER reviews the renter's information. 

4. The USER inputs a number of Authorized Amounts, days and required fields. 

5 . The USER submits the Authorization. 

6. The system validates information in the Customer File. 

7. If the adjuster assigned to the Customer File is 'UNKNOWN' or 'UNASSIGNED', the System 
will assign the Customer File to the current USER. 

8. The system will update the ARMSAVeb database with the Authorization, 

9. The System reads the user profile to see if the confirmation page should display. 

10. If the profile indicates 'Show Confirmation Page', the System will display the confirmation page 

11. This ends the use case. 



1.4.3 Alternative Flows 

1.4.3.1 View Notebook 

At step 3 of the Basic Flow, the USER can select to view the transaction history (Notebook) by 
selecting the Go To Notebook link. 

14.3.2 Add Notes to Customer File 

At step 3 of the Basic Flow, the USER can add notes to the Customer File by typing in the 
appropriate notes field on the Customer File page. 

14.3.3 Skip Customer File 

At step 3 of the Basic Flow, the USER should have the ability to skip to the next action item by 
clicking the Skip button. After clicking the Skip button, the USER should be taken to the next 
action item on their current list without any changes to the file being skipped. 

14.3.4 Change Customer File 

At step 3 of the Basic Flow, the adjuster can make changes to the additional details of the 
Customer File. This is done by selecting the Add / Change link which will invoke an editable 
page with all *appropriate information editable. 

1.5 Post-Conditions 

• If the use case was successful then the changes should go in to effect immediately and the screen 
should revert back to the original screen of entry. 

• If the use case was successful, then the ARMS system will be notified of authorization changes. 

• If the use case was unsuccessful then the system state will be unchanged. 

1.6 Special Requirements 

1.6.1 Requirements for Claim Type Autliorizations 

The following are a set of requirements surrounding the type of authorized amounts that are 
allowable based on the Claim Type associated with a rental. These restrictions DO NOT APPLY 
to reservations that are submitted with a Direct Billing Percentage of zero (0). 

1.6.1.1 When the Claim Type selected is 'Insured', Theft', or 'Uninsured Motorist' 

1 .6. 1 . 1 . 1 The reservation/rental must always include an Authorized Rate or both Policy 
Daily and Maximum Limits as defined by the renter's insurance policy. Zero (0) is an 
acceptable Policy Daily Limit. 



1 .6. 1 . 1 .2 The reservation/rental must include an Authorized Rate or Policy Daily Limit 
if a Policy Maximum Limit is included. Zero (0) is an acceptable Policy Daily Limit 





16.12 When the Claim Type selected is 'Claimant' 



1 .6. 1 .2 . 1 The reservation/rental must always include an Authorized Rate. 

1 .6. 1 .2.2 The reservation/rental may not include a Policy Daily/Maximum Limits 
selection. 

1.6.1.3 Requirements for editable fields based on reservation I ticket status 



1 .6. 1 .3. 1 Depending on the status of the Customer File the adjuster may change the 
following fields: 



Field Name 


Unassigned/Unauthorized 
Rcscrvfltiott/Tickct 


Assigned but 
Unauthorized 
Reservation or 
Ticket 


Authorized 
Ticket 


CLAIM NUMBER 


X 


X 


X 


CLAIM TYPE 


X 


X 


X 


LOSS TYPE 


X 


X 


X 


DATE OF LOSS 


X 


X 


X 


INSURED 
INFORMATION 


X 


X 


X 


RENTER 
INFORMATION 


X 






DATE RENTAL IS 
NEEDED 


X 






ADDITIONAL 
CHARGES 


X 


X 


X 


NUMBER OF 

AUTHORIZED 

DAYS 


X 


X 




BILL-TO PERCENT 


X 


X 


X 


POLICY LIMITS 


X 


X 


X 


AUTHORIZED 
1 RATE 


X 


X 


X 



If the Customer File is an Unauthorized Reservation, the adjuster can Reject the Authorization 
Request, Send a Message, and/or Transfer (Assign) the file to an adjuster. 
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1.6.1.3.2 If the status of the Customer File is an open ticket the following rules apply: 



Actions 


Authorized 
Reservation 


Unauthorized 
Reservation / 
Ticket 


Authorized 
Open Ticket 


Send Message 


X 


X 


X 


Extension 






X 


Terminate Rental 






X 


Cancel 

Authorization 


X 


X 




Transfer/Assign 
Adjuster 


X 


X 


X 


View Car Class 


X 


X 


X 



1.7 Extension Points 

An extension point indicates a link between this use case and another use case. Extension points associated 
with the use case are indicated below. Clicking on the extension point will open the related use case. 

17.^ MA-04 Send A Message 

The Send Message will be used to allow the user to capture messages and diary notes associated 
with a rental reservation/authorization. The USER can elect to either have the message sent to the 
Enterprise rental branch location responsible for the reservation/authorization, or to store the note 
in the ARMS Web system without sending the message to Enterprise. All MESSAGES and 
DIARY NOTES captured must be related to a specific reservation/authorization. 

1.7.2 MA-16 Transfer Work 

(The Change Adjuster button invokes this use case). 

The ADJUSTER may choose to transfer an authorization to a different adjuster in his/her office or 
transfer the authorization to another adjuster in a different office. 

1.7.3 MA-08 View Car Class 

The ADJUSTER may choose to view the car class. This button invokes the View Car Class use 
case. 

1.7.4 MA-17 Cancel Authorization 

The ADJUSTER may choose to deny the authorization. When the ADJUSTER selects the 
CANCEL button, it will invoke the Cancel Authorization use case to reject the authorizatio 
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Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

Authorize Rental Detail 

This screen will allow the user to work the currently selected authorization request. The user may set the 
authorization amounts and policy coverage limits or may assign the request to another adjuster. 
2.1.1 Screen Layout - Authorize Rer)tal Detail - c^ir-£ ^ 




Functional Des^n S 

2.1.2 
Handling For: 


peciftcalion 

Authorize Rental De 


tail 

landling for Adjuster's 


~irst Name + Last 1 


Issue: "^'^•^ 
^ksuepate: 10/20/00\ 


Note to 


nput 


3 


Message 


viOTE 
NOTE 




Notebook 
Note to Self 
Only 


Output 
Input 


50 
0 


\4essage 
Vlessage 


NOTE 




Message 


Output 
Output 


8 


Message Creation Date 
Message Text 


Add Date 
NOTE 


N/A. 
N/A. 


Claim no. 


Output 
Output 


10 

30 


Notebook creation date 
Claim Number 


Add Date 
Number 




Claim Number. 


Input 


11 


Claim Number 


Number 


N/A. 




input 


4 


Number of Days 
Authorized 


Number Of Days 
Authorized 


N/A. 


Direct Bill %: 




6 


Percent Covered 


Bill To % 


N/A. 


Policy: Daily 
rate/Maximum 
dollars: 


List Box 


5 


Policy Maximum and 
Daily Rates 


Dollars Per Day 
Covered 


N/A. 


Policy: Daily 
rate/Maximum 
dollars: 


List Box 


5 


Policy Maximum and 
Daily Rates 


Max $ Covered 


N/A. 




Output 


30 


Rental Location Branch 


Rental Location 


N/A. 


Date Rental 
Needed: 


List Box 


10 


Rental Start Date 


Start Date 


N/A. 


days (fl), 






Vehicle Rate 


Vehicle Rate 


N/A. 


Insured Name: 


Input 


30 


Insured's Name 


First Name + Last 




Insured Name: 


Output 


20 


Insured's Name 


First Name + Last 






Output 


30 


Rental Location 
Address 


Address Line2 






Output 


25 


Rental Location City 








Output 


10 


Rental Location Postal / 
Zip Code 




N/A. 




Output 


3 


Rental Location State / 
Province Code 








Output 


13 


Rental Location 
Telephone Number 


Telephone Number 


N/A. 


Date of Loss: 


List Box 


10 


Date of Loss 


Date Of Loss 


N/A. 


Date of Loss 


Output 


10 


Date of Loss 


Date Of Loss 






Output 


30 


Renter's Address Line 


Address Line 




Address 


Output 


20 


Renter's City 


City 






Output 


3 


Renter's State /Province 
Code 


State 






Output 


15 


Renter's Zip/Postal 
Code 


Zip Code 






Furietional ©esign Spec 











Renters Night Phone 
+ Renters Night 
Phone Extensin 


This field is input if the ticket is not 


Home Phone: 


Output 




opened. It will not be editable if the 
ticket is open. 


Authoriz Direct 
Bill: for 


Output 


30 


Renter's Name 


First Name + Last 


N/A. 


Renter: 


Output 


30 


Renter's Name 


First Name + Last 






Output 




Renter's Work Phone 


Day Phone + Renters 
Day Phone Extension 




Owner's Vehicle 


Output 


20 


Vehicle Year, Make and 
Model 


Renter Vehicle Year 
+ Renter 
Make/Model 






Output 


15 


Repair Facility City 


City 




Repair Facility 




20 


Repair Facility Name 


Repair Facility Name 






Output 




Repair Facility State 








Output 


10 


Repair Facility 
Telephone Number 


Telephone Number 






Output 


7 


Repair Facility Zip 


Zip Code 




Claim Type: 


List Box 


15 


Claim Type 


claim type 
description 


N/A. 


Claims Office: 


Output 


3 


Office Id 


external organization 


N/A. 


Vehicle 
Condition 


List Box 


20 


Loss Type 


loss type description 




Vehicle 
Condition 


Output 


20 


Type of Loss 


loss type description 








20 


Renter's Email 







Screen Function Definition 

This section includes the definitions for all fiinctions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Skip 

When clicked, the USER will be taken out of the use case without changing the current status of 
the request. Any changes made by cHcking Change or Add and keying data in the bottom section 
will be saved. 

2.1.3.2 Process 

When clicked, the system will validate the input and accept the changes made to the customer file. 
The arms database will be updated and the data will be sent to the arms system. The use case will 
then end and the USER will return to the process from which they came. 

2.1.3.3 Notet)Ook 

When clicked, the USER will be taken to the Note Book section at the bottom of the screen to 
view all messages for this rental. 
2.13.4 Transfer File 

When clicked, the USER will be taken to the Transfer File screen. This screen allows the USER 
to change the office or adjuster currently assigned to the customer file. The required information 
in die Extend Rental/Customer File will be passed to the Transfer File screen. Upon completion 
of the transfer, the USER will then be returned to the next action item or the profiled start page, 
depending on the screen from which the USER began. 
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2.13.5 Change or Add 

When clicked, the system will refresh the current screen and make all editable fields in the bottom 
section (outside the gray box area) input capable. The changes on the top of the screen w,ll not be 



2.1.3.6 Top of page 

When clicked, the USER will be taken to the top of the current page. 

2.1.3.7 View Car Class 

When cUcked, the USER will be taken to the View Car Class Use Case. No changes will be lost. 
Once the USER is finished with this use case, the USER will return to the Extend Rental Use 
Case. 
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3. Application Operations 
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Data Fields 

Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 Add Date 



Entity 


ARM: ARMS/400 Diary Notes File 




Column Name 


NEADDT 


Label Name 


Add Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 





4.1.2 Address Line 



Entity 


ARM: Rental Location Master 


Column Name 


LOADLl 


Label Name 




System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.1.3 Address Line 



Entity 


ARM: Renter Detail 


Colunm Name 


RKADLl 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.1.4 Address Line2 



Entity 


ARM: Rental Location Master 


Column Name 


L0ADL2 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.15 Bill To % 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZBTPC 


Label Name 


Bill To % 
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4.1.6 Branch 



Entity 


A4 Cross Reference 




Column Name 


ir id 


Label Name 


Branch: 




System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.17 City 




Entity 


ARM: Rental Location Master 




( 'olumn Name 


LOCYNM 




Label Name 


City 




System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.18 City 


Entity 


ARM: Renter Detail 


Column Name 


RKCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.9 City 


Entity 


ARM: Repair Detail 


Column Name 


RUCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1^0 claim type code 


Entity 


AUTHORIZATION EXTENSION 


Column Name 


elm typ ode 


Label Name 


claim type code: 


System Name 


CLMTYPCDE 


Data Type 


DEC(3,0) 
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Attribute Definition 



The claim type code defines the different Authorization claim 
types. For example: Insured, Claimant, Uninsured Motorist, 



4.1.11 claim type description 



Entity 


CT AIM TYPE 


Colunm Name 


elm typ dsc 


Label Name 


claim type description: 


System Name 


CLMTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The claim type description is a lexical definhion of the claim 
type code which defines the different Authorization claim types. 
For example: Insured, Claimant, Uninsured Motorist, etc. 



4.1.12 company identifier 



Entity 


EXTERNAL ORGANIZATION 


Colunm Name 


cmpy id 


Label Name 


company identifier: 


System Name 


CMPYID 


Data Type 


DEC(11,0) 


Attribute Definition 


Business Party Identifier is a surrogate key assigned to each 
unique occurrence of an Individual, External Organization, and 
Internal Organization (Business Party). 



4.1.13 Date Of Loss 



Entity 


ARM: Renter Detail 


Column Name 


RKLSDT 


Label Name 


Date Of Loss 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 





4.1.14 Day Phone 



Entity 


ARM: Renter Detail 


Column Name 


RKDYPH 


Label Name 


Day Phone 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 





4.1.15 Dollars Per Day Covered 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZ$PDY 



Label Name 


Dollars Per Day Covered 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 





4.1.16 external organization abbreviated name 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


e 0 abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(IO) 


Attribute Definition 


Extemal Organization Abbreviated Name is a shortened text 
based label associated with an organization outside of 
Enterprise. This name is sometimes used for accounting 
purposes. 



4.1.17 extemal organization identifier 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


e 0 id 


Label Name 


extemal organization identifier: 


System Name 


EOID 


Data Type 


DEC(11,0) 


Attribute Definition 


The extemal organization identifier is a surrogate key assigned 
to each unique occurrence of an Extemal Organization. 
Examples: body shops, vehicle manufacturers, insurance 
companies, leasing accounts, credit unions, dealerships, or 
government agencie 



4.1.18 First Name 



Entity 


ARM: Adjustor Master 




Column Name 


ALFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 





4.1.19 First Name 



Entity 


ARM: Insured Detail 


Colvinm Name 


IRFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 






4.1.20 First Name 



Entity 


ARM: Renter Detail 




Column Name 


RKFSNM 




Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.1.21 Group 


Entity 


A4 Cross Reference 


Column Name 


grp id 


Label Name 


Group Number 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.122 Insurance Claim Number 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.123 Last Name 


Entity 


ARM: Adjustor Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.124 Last Name 



Entity 


ARM: Insured Detail 


Column Name 


IRLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 






4.1.25 Last Name 



Entity 


ARM: Renter Detail 




Column Nanie 


RKLSNM 




Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.1.26 loss type code 



Entity 


AUTHORIZATION EXTENSION 


Colvimn Name 


loss typ cde 


Label Name 


loss type code: 


System Name 


LOSSTYPCDE 


Data Type 


DEC(3,0) 


Attribute Definition 


The loss type code defines the different loss categories when an 
Insurance Company authorizes a Rental. For example: Theft, 
Drivable, Repairable, Non-drivable, Non-repairable, Totaled. 



4.127 loss type description 



Entity 


LOSS TYPE 


Column Name 


lossjypdsc 


Label Name 


loss type description: 


System Name 


LOSSTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The loss type description is a lexical definition of the loss type 
code which defines the different loss categories when an 
Insurance Company authorizes a Rental. For example: Theft, 
Drivable, Repairable, Non-drivable, Non-repairable, Totaled. 



4.1.28 Max $ Covered 



Entity 


ARM: Authorization(Claim Info) 


Colunm Name 


AZ$MAX 


Label Name 


Max $ Covered 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 





4.1.29 NOTE 

Entity [ ARM: ARMS/400 Diary Notes File 

Column Name NENOTE 

Label Name NOTE 

System Name 

Data Type | CHAR(50) 




Issuedate:;6/20/00 



[ Attribute Definition | 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZAUDY 


Label Name 


Number Of Days Authonzed 


System Name 




Data Type 


DECIMAL(3) 


Attribute Definition 





4.1.31 Rental Location 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZRNLC 




Label Name 


Rental Location 


System Name 




Data Type 


CHAR(IO) 


Attribute Definition 




4.1.32 renter email 


Entity 


RENTER EXTENSION 


Column Name 


rentr eml 


Label Name 


renter email: 


System Name 


RENTREML 


Data Type 


CHAR(70) 


Attribute Definition 


The email address of the renter. 



4.1.33 Renter Mal<e/Model 



Entity 


ARM: Renter Detail 


Column Name 


RKVHMM 


Label Name 


Renter Make/Model 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.1.34 Renter Vehicle Year 


Entity 


ARM: Renter Detail 




Column Name 


RKVHYR 


Label Name 


Renter Vehicle Year 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 





Confi^tial j 
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Entity 


ARM: Renter Detail 


Column Name 


RKDYEX 


Label Name 


Renters Day Phone Extension 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 




4. 1.36 Renters Night Phone 


Entity 


ARM: Renter Detail 


Column Name 


RKNTPH 


Label Name 


Renters Night Phone 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4. 1 37 Renters Night Phone Extensin 


Entity 


ARM: Renter Detail 


Column Name 


RKNTEX 


Label Name 


Renters Night Phone Extensin 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 




4. 1 38 Repair Facility Name 


Entity 


ARM: Repair Detail 


Column Name 


RURFNM 


Label Name 


Repair Facility Name 


System Name 




Data Type 


CHAR(35) 


Attribute Definition 




4.1.39 Start Date 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZSTDT 


Label Name 


Start Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.1.40 State 


1 Entity 


1 ARM: Rental Location Master 






Column Name 


LOSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 








Entity 


ARM. Kcnter jjeiau 


Column Name 


RKSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.42 State 


Entity 


ARM: Repair Detail 


Column Name 


RUSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4. 1.43 Status Description 


Entity 


ARM: ARMS/400 Cross Reference Status Table File 


Column Name 


XUSTDS 


Label Name 


Status Description 


System Name 




Data Type 


CHAR(6) 


Attribute Definition 




4.1.44 Teleptione Number 


Entity 


ARM: Rental Location Master 


Column Name 


LOPHNO 


Label Name 


Telephone Number 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4.1.45 Telephone Number 


Entity 


ARM: Repair Detail 


Column Name 


RUPHNO 


Label Name 


Telephone Number 



Functional DesJgs^ecifio&tion 



System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4.146 Vehicle Class 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZVHCS 


Label Name 


Vehicle Class 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.47 Vehicle Rate 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZVHRT 


Label Name 


Vehicle Rate 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 




4.1.48 Zip Code 


Entity 


ARM: Rental Location Master 


Column Name 


LOZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 
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4.1.49 Zip Code 






Entity 


ARM: Repair Detail 


Column Name 


RUZPCD 


Label Name 


Zip Code 




System Name 




Data Type 


CHAR(9) 


Attribute Definition 
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Questions and Answers 



Issue Number: 419 



Question: 6-23-00, When rejecting an authorization do we want a reason code? 
Per Jennifer - Mike, Brad and Craig is handling this. 



Status: Pending 



Resolution: 07-03-00 - Brad Reel: In the ARMS Web V2.0 application reason 
codes will be collected for the following events: reject mvoice, terminate 
authorization. Per a discussion with Randy Haselhorst, it would be worthwhile to 
collect a reason code for for reject/cancel authorization. However, it is not critical 
for this release. If possible it should be incorporated. 
07-03-00 - Brad Reel: I am reassigning to Mike Slater to work with Neil 
Fitzgerald and determine whether or not to incorporate in V2.0, or wait until a 
later release. 
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Change Customer File 

1 . Change Customer File Use Case 

1.1 Brief Description 

The Change Authorization use case describes how the USER could change an authorization assigned 
to a reservation or an open rental. 

1 .2 Use Case Actors 

The following actors will interact with this use case: 

• ADJUSTER - The USER will use this case to add or change information related to an existing 
Customer File on a rental within ARMS Web. 

1.3 Pre-Conditions 

• The USER must be logged into the ARMS Web system. 

• The USER must have selected to change an existing Customer File. 

1.4 Flow of Events 

The Flow of Events will include the necessary steps to make changes to a Customer File. 





14.2 Basic Flow 

1 . The USER will select a Customer File to change. 

2. The SYSTEM will display the associated Customer File detail of the selected item. 

3. The USER will add additional or modify existing information associated with the Customer 
File. 

4. The SYSTEM will validate added or modified data. 

5 . The SYSTEM will update ARMS Web to reflect the changes. 

6. The SYSTEM notifies ARMS of the changes associated with the Customer File. 

7. The SYSTEM checks the profile for the confirmation screen setting. 

8. This ends the use case. 

1.4.3 Alternative Flows 

1.4.3. 1 View Rental Notebook 

At step 1, the USER may choose to view the history of a rental. The USER will be able to see 
the last five diary notes. The USER can also select to view the transaction history or add 
diary notes from the Extend Rental Detail. 

1.4.3.2 Validate Changes 

If the USER changes or adds information, which does not pass validation, an error message 
will notify the USER and return them to step 1 of the Basic Flow. 

If an error is discovered in the validation of the reservation / rental information submitted by 
the USER (Step 3 of the Basic Flow), the system would present the USER with an error 
message and return them to the Detailed Reservation / Rental Display. If the error is specific 
to a data field within the form, the field should be highlighted and the error described. 

1.4.3.3 Display Confirmation 

After step 6, the USER may wish to have a confirmation page displayed, indicating that some 
type of change has taken place. The confirmation page is completely optional, therefore, at 
anytime the USER wants to set their profile to bypass this screen, he/she may do so. 

1.4.3.4 Update USER Profile 

During the confirmation process, the USER has the option of changing their profile setting to 
display or hide the confirmation page. Each time the setting is changed, the USER profile 
must be updated to reflect the new requirements set by the USER. 



1.5 Post-Conditions 

• If the use case was successful then the changes have been saved to the ARMS Web database 
and if appropriate, ARMS Web has generated notification transactions to ARMS. 

• If the use case was unsuccessful then the system has remained unchanged. 

1.6 Special Requirements 

• It will be considered invalid if for a reservation, the Claim Number, Renter First Name, Renter 
Last Name, Claim Type, Vehicle Condition, Rental Location, Authorized Number of Days, Direct 
Bill Percent, and at least one Renter Telephone number have not been included. 

• It will be considered invalid if the customer has established Claim Number editing and the Claim 
Number format does not meet the requirements of the customer's Claim Number defmition. 





It will be considered invalid if anyTleld identified as REQUIRED in the company/office profile is 
not included. 



• It will be considered invalid if any data entered violates the data type as specified by the ARMS 
Web database (i.e., alpha characters in a numeric field). 

• A warning will be presented to the USER if any defined limits identified in the 
company/office/user profile are exceeded (e.g., Maximum Number of Days Authorized). The 
system will allow the USER to submit the authorization from the warning. 

• It will be considered invalid if the selected Claim Type is 'Insured,' 'Uninsured,' or 'Theft' and 
the reservation does not include an Authorized Rate or does not include both Policy Daily and 
Policy Maximum Limits (with the exception of reservations with a Direct Bill Percent of zero (0)). 
A Policy Daily Limit of zero (0) is an acceptable entry. 

• It will be considered invalid if the selected Claim Type is 'Insured,' 'Uninsured,' or 'Theft' and 
the reservation includes a Policy Maximum Limit but does not include an Authorized Rate ot 
Policy Daily Limit (with the exception of reservations with a Direct Bill Percent of zero (0)). A 
Policy Daily Limit of zero (0) is an acceptable entry. 

• It will be considered invalid if the selected Claim Type is 'Claimant' and Policy Limits (Daily or 
Maximum) have been included. 

• It will be considered invalid if the Authorized Number of Days is included and is less than zero 
(0). 

• It will be considered invalid if the Direct Bill Percent is greater than zero (0) and the Authorized 
Number of Days is zero. 

• It will be considered invalid if the Direct Bill Percent is less than zero (0). 

• It will be considered invalid if the Direct Bill Percent is greater than one hundred ( 1 00). 

• It will be considered invalid if the Labor Hours are less than zero (0). 

• It will be considered invalid if the Date of Loss is greater than the current date. 

• It will be considered invalid if the first three digits (i.e., area code) of any U.S. or Canadian 
telephone number meet the criteria below: 

• OXX 

• IXX 

• The second and third digits equal (e.g., 800, 877, 888, etc.) 
Where X equals any digit 0 through 9. 

• It will be considered invalid if a U.S. or Canadian telephone number does not consist of 10 digits. 

• It will be considered invalid if a U.S. postal code does not consist of 5 or 9 digits. 

• It will be considered invalid if a Canadian postal code does not consist of 6 alphanumeric 
characters in the format AXAXAX where A is an alpha character and X is a digit between 0 and 9. 




/" — / ■'' Issuer, y/I^l 

Change C^tomerplfe-^^ ^/ - Issue Dat&r<0/20/00 

• It will be considered invalid if an E-mail address is included that does not include an '@' 
character. 

• It will be considered invalid if the Send e-mail Confirmation to Renter flag is set to true and the 
Renter e-mail address is not included. 

• If the customer file is in reservation status, the screen will show a cancel button for the USER to 
cancel the authorization if desired. 

• If the customer file is in open ticket status, the screen will show the set last day button for the 
USER to terminate the rental if desired. 



1.1 A MA-04 Send a Message 

The Send Message will be used to allow the USER to capture messages and diary notes 
associated with extending a rental. The USER can elect to either have the message sent to the 
Enterprise rental branch location responsible for the reservation/authorization, or to store the 
note in the ARMS Web system without sending the message to Enterprise. All MESSAGES 
and DIARY NOTES captured must be related to a specific reservation/authorization File. 

1.7.2 MA-16 Reassign USER or Office (The Transfer File button invokes this use case). 
After the extend rental detail is displayed, the USER may choose to change the current 
office/USER. First, the USER would select to change the current office/USER. Second, the 
system would display a list of authorized offices/users. Third, the USER would select a new 
office/USER. 

1. 7.3 MA-15 Terminate a Rental (Set Last Day) 

After the extend rental detail is displayed, the USER may choose to terminate the rental. If 
termination is selected, the USER must enter a reason for the termination of the rental. 
Termination means the insurance company is no longer willing to pay for the rental. This 
fiinction (button) is only available for an open ticket. For reservation status, the USER should 
see the Cancel button. 

1.7.4 MA-1 7 Cancel Auttiorization 

Before step 5 of the Basic Flow, the USER should have the capability to cancel the 
authorization. Before the USER has made changes that have been updated in the database 
and sent to ARMS, the Cancel Authorization fimction (button) should be available for 
reservation stahis. However, the USER cannot perform the Cancel fiinction on an open ticket. 
For an open ticket, the Termination (Set Last Day) fiinction (button) is available. 

1 7.5 MA-08 View Car Class 

The View Car Class use case will be used to allow the USER to view details about and select 
a car class to apply to a reservation. Details will include the average number of passengers 
and luggage items that can be served by a vehicle in the specific car class. The car class 
selected by the USER should be applied to the reservation. 
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Screen Design 

A definition of the screen layout(s.), screen data fields, and screen functions that are used to implement 
the flows identified above. More than one screen may be used to implement support for the use ci 
flow. 

Change RentelJtetaiL =^ (^S^ecVi^Ur 

This screen'V(alfallow the USER to work the currently selected authorization request. The USER may 
set the authorization amounts and policy coverage limits or qga|^,assjgn- a^^fqi^estJo^apgtljer adjuste r^^ 
Screen Layout- Change Rental DetJ(Amr clicking the Change or Add link) 



2.1.1 



inJ/changeOiMdhtml 



Ajtcmated lent.) I'^lsnagenen; Sv-iem 



Claims Office;! 001 



Address: 1 1735 N. Paulina St. 

City; j Chicago Stale: | IL ^Z!p:|B0622 



Enterprise Rent-A-Car Locatio 

Enterprise Edgewater Branch 
5400 N. Ashland 
Chicago. IL 60622 
773-334-5400 



t Craig 



Owner's vehicle; |GMC Subuiian 1999 ! 

Date of LOSS {J^lir«-1[5S51B 
Vehicle Condition;] Non-Dnwable g 



[Home ii 1(773)564^05^ i Ext; f 
IWprk g 1(77^335-6200 ^ i Ext; [ 



Email; j thanl<s@iefer 
W Requested email 




Issue: / vl.rv 
-t§sueQAe:10/20/0y 



(Before clicking the Change or Add Link) 



Automated Rental Management System 



Claims Officf 



ing for: Yourself 



You authortgg d 3 tigys at $29.39/d^y for Han ks. Tom 
Custonm^r^FiJe: for Bowie, David Claim no. 7B5849322-001 




Bowie. David 

1735 N. Paulina St. 

Chicago. IL 60622 



Authorized Class: Standard 
Days/Rate: 5 days @ $21 .99/d3y 
Current Class: Full-Size 
Additional Charges: None 
Direct Bill %: None 
Rental Date: 03/28/2000 
Start Date: 03/2O/20OO 



Claim Number: 32323232323232323 

Claim Type: Theft 

Insured Name: Lalumandier, Craig 

Owner's vehicle: GMC Suburban 1999 

Date of Loss: O3/28/20OO 

Loss Type: Non-Drivable 

Policy: Daily rate/ 

Maximum dollars: 30/600 



Home: (773)564-6054 
Work: (773)395-6200 
Email: dbowie@zefer. cor 
Requested email confirrr 



Enterprise Rent^-Cai 

Enterprise Edgewater E 
5400 N. Ashland 
Chicago. I L 60622 
773-334-5400 



Repair Facility: 

EIco Chevrolet 
Chicago. IL 60621 
(773)334-9832 



Message. Belanger. Hugues. 2/20/00 

Note from Enterprise. Sarussi. Marty. 2/21/00 

Extension Request, 2/24/00 

Extension. 2/25/00 





2.1.2 Change Rental Detail 











Additional 
Charges 


Output 


15 


Additional Charges 






Handling For: 


Output 


30 


Handling for Adjuster's 


First Name + Last 
Name 


Last Name + First Name 


Note to Self 
Only 




50 


Message 


NOTE 




Messages: 


Output 


8 


Message Creation Date 


Add Date 


N/A. 


Note to 
Enterprise: 




50 


Message Text 


NOTE 






Output 


50 


Message Text 


NOTE 


N/A. 


Claim 
Number: 


Output 


11 


Claim Number 


Insurance Claim 
Number 




Days 

Authorized to 
Date: 


Output 


2 


Number of Days 
Authorized 


Number Of Days 
Authorized 


N/A. 


additional 
authorized 
days 


Output 


2 


Number of Days to 
Extend 


Number of Days to 




Policy Limits 


List Box 


5 


Dollars per day 


Max $ Covered + 
Dollars Per Day 






Output 


30 


Rental Location Branch 


Rental Location 




days @: 


List Box 


6 


Rental Location Rate 


Vehicle Rate 


N/A. 


Date of 


Output 




Rental Start Date 


Start Date 


N/A. 


Insured 


Output 


30 


Insured's Name 


First Name + Last 






Output 

... 


30 


Rental Location 
Address 


Address Line + 
Address Line2 


N/A. 




utput 


25 


Rental Location City 


City 


N/A. 




Output 


10 


Rental Location Postal / 
Zip Code 


Zip Code 


N/A. 




Output 


3 


Rental Location State / 
Province Code 


State 


N/A. 




Output 


13 


Rental Location 
Telephone Number 


Telephone Number 


N/A. 


Date of Loss: 


Output 


10 


Date of Loss 


Date Of Loss 






Output 


20 


Renter City Name 


City 






Output 


10 


Renter Postal / Zip 
Code 


Zip Code 






Output 




Renter State / Province 
Code 


State 






Output 


30 


Renter Street Address 


Address Line 






Output 


16 


Renter's Home Phone 


Renters Night Phone 
+ Renters Night 
Phone Extensin 


Not editable if ticket is Open. 




Output 


30 


Renter's Name 


First Name + Last 


Will not be editable if ticket is open. 
First Name + Last Name 


Information: 


Output 


30 


j Renter's Name 


First Name + Last 
Name 


N/A. 












Will not be able to edit if ticket is 
Open. 


Work Phone: 


Output 


16 


Renter's Work Fhone 


Day Phone + Renters 
Day Phone Extension 


Owner's 
vehicle: 


Output 


— 


Vehicle Year Make and 
Model 


Renter Make/Model 
+ Renter Vehicle 




Repair 
Facility: 


'o^t 


20 


Body Shop Name 


Repair Facility Name 








16 


Body Shop Phone 
Number 


Telephone Number 






Output 


15 


Repair Facility City 


City 






Output 


3 


Repair Facility State 


State 






Output 


7 


Repair Facility zip code 


Zip Code 




Last Day 
authorized 


Output 


10 


Date rental is 
authorized through 


CALCULATED 


Calculated field. Populated with an 
Open Ticket only. 


Charges to 
bate: 


Output 


10 


Total Charges 


CALCULATED 




Renter Type 


Output 


10 


Claim type 


claim type 
description 




Claims 
Office: 


Output 


3 


Office Id 


external organization 
abbreviated name 


N/A. 


Vehicle 
Condition 


Output 


15 


Type of Loss 


loss type description 




Renter Email: 1 Output 


20 


Renter's Email 


renter email 


Will not be able to edit if ticket is 
Open. 



2. 13 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 S/c;p 

When clicked, the USER will be taken out of the use case without changing the current status 
of the request. Any changes made by clicking Change or Add and keying data in the bottom 
section will be saved. 

2.1.3.2 Process 

When clicked, the system will validate the input and accept the changes made to the customer 
file. The arms web database will be updated and the data will be sent to the arms system. 
The use case will then end and the USER will return to the process from which they came. 

2.1.3.3 Noteboola 

When clicked, the USER will be taken to the Note Book section at the bottom of the screen to 
view all messages for this rental. 

2.13.4 Set Last Day 

When clicked, the system will terminate the rental. The USER will be prompted to enter a 
termination date for this rental. This coincides with the use case MA-15-Terminate Rental. 

2.1.3.5 Transfer File 

When clicked, the USER will be taken to the Transfer File screen. This screen allows the 
USER to change the office or adjuster currently assigned to the customer file. The required 
information in the Extend Rental/Customer File will be passed to the Transfer File screen. 
Upon completion of the transfer, the USER will then be returned to the next action item or the 




/ 




X 



profiled start page, depending on the screen from which the USER began. 

2.1.3.6 Change or Add 

When clicked, the system will refresh the current screen and make all editable fields in the 
bottom section (outside the gray box area) input capable. The changes on the top of the 
screen will not be lost. 

2.1.3.7 Top of page 

When clicked, the USER will be taken to the top of the current page. 

2.1.3.8 View Car Class 

When clicked, the USER will be taken to the View Car Class Use Case. No changes will be 
lost. Once the USER is finished with this use case, the USER will return to the Extend Rental 
Use Case. 

2.1.3.9 Extend Rental (checkbox) 

When checked and the process button is clicked, the system will validate the input and accept 
the extension AND any other changes made to the customer file. The arms web database will 
be updated and the data will be sent to the arms system. The use case will then end and the 
USER will proceed to the next action item. (If unchecked and the process button is clicked, 
only the changes to the screen will be saved. The extension will NOT be executed.) 

2.1.3.10 Last Action l\/1essage 

After each action item in the USER'S list has been completed, upon arriving at the next item 
there will be a confirmation message at the top of the screen. This message will be a 
hyperlink describing the last completed action. If the USER clicks on this link, the system 
will open the customer file, which will reflect all of the current information for the rental. 
The USER is then free to make additional changes or to simply view the file. 
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3. Application Operations 





4. Data Fields 

4.1 Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 Add Date 



Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NEADDT 


Label Name 


Add Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 





4.12 Address Line 



Entity 


ARM: Rental Location Master 


Column Name 


LOADLl 


Label Name 




System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.1.3 Address Line 



Entity 


ARM: Renter Detail 


Column Name 


RKADLl 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.1.4 Address Line2 



Entity 


ARM: Rental Location Master 


Column Name 


L0ADL2 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.1.5 Branch 



Entity 


ARM: Rental Location Master 


Colunm Name 


Branch 


Label Name 


Branch: 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 
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4.1.6 City 



Entity 


ARM: Rental Location Master 


Column Name 


LOCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.17 City 


Entity 


ARM: Renter Detail 


Column Name 


RKCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.8 City 


Entity 


ARM: Repair Detail 


Column Name 


RUCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.9 claim type code 


Entity 


AUTHORIZATION EXTENSION 


Column Name 


clmtypcde 


Label Name 


claim type code: 


System Name 


CLMTYPCDE 


Data Type 


DEC(3,0) 


Attribute Definition 


The claim type code defines the different Authorization claim 
types. For example: Insured, Claimant, Uninsured Motorist, 
etc. 


4.1.10 claim type description 


Entity 


CLAIM TYPE 


Column Name 


elm typ_dsc 


Label Name 


claim type description: 


System Name 


CLMTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The claim type description is a lexical definition of the claim 
type code which defines the different Authorization claim types. 


\ ^~ - ^ 



r-x. r /■ /'"•>ue: /^>\ 
Change C^lstomef Filg J '^--^^^ '"-•^■^ IssutiWe: 10/20/00 

[ I For example: Insured, Claimant, Uninsured Motorist, etc. [ 



company identifier 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


cmpyid 


Label Name 


company identifier: 


System Name 


CMPYID 


Data Type 


DEC(11,0) 


Attribute Definition 


Business Party Identifier is a surrogate key assigned to each 
unique occurrence of an Individual, External Organization, and 
Internal Organization (Business Party). 



4.112 Date Of Loss 



Entity 


ARM: Renter Detail 


Column Name 


RKLSDT 


Label Name 


Date Of Loss 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 





4.1.13 DayPfione 



Entity 


ARM: Renter Detail 


Colunm Name 


RKDYPH 


Label Name 


Day Phone 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Defmition 





4. 1. 14 external organization abbreviated name 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


e 0 abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(IO) 


Attribute Definition 


External Organization Abbreviated Name is a shortened text 
based label associated with an organization outside of 
Enterprise. This name is sometimes used for accounting 
purposes. 



4.1.15 external organization identifier 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o id 


Label Name 


external organization identifier: 




System Name 


EOID 


Data Type 




Attribute Definition 


The external organization identifier is a surrogate key assigned 
to each unique occurrence of an External Organization. 
Examples: body shops, vehicle manufacturers, insurance 
companies, leasing accounts, credit unions, dealerships, or 
government agencie 



4.1.16 First Name 



Entity 


ARM: Adjustor Master 


Column Name 


ALFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 





4.1.17 First Name 



Entity 


ARM: Insured Detail 


Column Name 


IRFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 





4.1.18 First Name 



Entity 


ARM: Renter Detail 


Column Name 


RKFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 





4.1.19 Group 



Entity 


ARM: Rental Location Master 


Column Name 


Group 


Label Name 


Group Number 


System Name 




Data Type 


CHAR(2) 


Attribute Defmition 





4.1.20 Insurance Claim Number 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCLNO 
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Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.21 Last Name 


Entity 


ARM: Adjustor Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.22 Last Name 


Entity 


ARM: Insured Detail 


Column Name 


IRLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.23 Last Name 


Entity 


ARM: Renter Detail 


Column Name 


RKLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.24 loss type code 


Entity 


AUTHORIZATION EXTENSION 


Column Name 


losstypcde 


Label Name 


loss type code: 


System Name 


LOSSTYPCDE 


Data Type 


DEC(3,0) 


Attribute Definition 


The loss type code defines the different loss categories when an 
Insurance Company authorizes a Rental. For example: Theft, 
Drivable, Repairable, Non-drivable, Non-repairable, Totaled. 


4.1.25 loss type description 


Entity 


LOSS TYPE 


Column Name 


loss_typ_dsc 





Label Name 


loss type description: 


System Name 


T /^CCTVOTkCr^ 
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Data Type 


CHAR(40) 


Attribute Definition 


The loss type description is a lexical definition of the loss type 
code which defines the different loss categories when an 
Insurance Company authorizes a Rental. For example: Theft, 
Drivable, Repairable, Non-drivable, Non-repairable, Totaled. 


4. 1.26 message ecars indicator 


Entity 


AUTHORIZATION MESSAGE 


Column Name 


msgecarsind 


Label Name 


message ecars indicator: 


System Name 


MSGECARIND 


Data Type 


CHAR(l) 


Attribute Definition 


The message ecars indicator indicates whether the message is 
sent/received fi-om the ecars system. 


4.1.27 NOTE 


Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NENOTE 


Label Name 


NOTE 


System Name 




Data Type 


CHAR(50) 


Attribute Definition 




4.1.28 Number Of Days Authorized 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZAUDY 


Label Name 


Number Of Days Authorized 


System Name 




Data Type 


DECIMAL(3) 


Attribute Definition 




4.1.29 Rate Charged 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZRTCH 


Label Name 


Rate Charged 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 




4.130 Rental Location 


\ Entity 


ARM: Authorization(Claim Info) 
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Column Name 


AZRNLC 


Label Name 


Rental Location 


System Name 




Data Type 


CHAR(IO) 


Attribute Definition 




4.-/.37 renter email 


Entity 


RENTER EXTENSION 


Colunm Name 


rentr_eml 


Label Name 


renter email: 


System Name 


RENTREML 


Data Type 


CHAR(70) 


Attribute Definition 


The email address of the renter. 


4. 132 Renter Make/Model 


Entity 


ARM: Renter Detail 


Column Name 


RKVHMM 


Label Name 


Renter Make/Model 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4. 1 33 Renter Vehicle Year 


Entity 


ARM: Renter Detail 


Column Name 


RKVHYR 


Label Name 


Renter Vehicle Year 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 




4.1.34 Renters Day Phone Extension 


Entity 


ARM: Renter Detail 


Column Name 


RKDYEX 


Label Name 


Renters Day Phone Extension 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 




4.1.35 Renters Night Phone 


Entity 


ARM: Renter Detail 


Colmnn Name 


RKNTPH 


Label Name 


Renters Night Phone 




/ X 
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System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4.1.36 Renters Night Phone Extensin 


Entity 


ARM: Renter Detail 


Column Name 


RKNTEX 


Label Name 


Renters Night Phone Extensin 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 




4.1.37 Repair Facility Name 


Entity 


ARM: Repair Detail 


Column Name 


RURFNM 


Label Name 


Repair Facility Name 


System Name 




Data T3^e 


CHAR(35) 


Attribute Definition 




4.1.38 standard message description 


Entity 


STANDARD MESSAGE 


Column Name 


std msg dsc 


Label Name 


standard message description: 


System Name 


STDMSGDSC 


Data Type 


CHAR(50) 


Attribute Definition 


The standard message description is a lexical definition for 
standard message code which defines a predefined message 
which is applicable to specific activity type codes. For 
example: "Authorization confirmed on &Date with Reservation 
Number &Resnumber" 


4.139 Start Date 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZSTDT 


Label Name 


Start Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.140 State 


Entity 


ARM: Rental Location Master 


Colvum Name 


LOSACD 
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Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.41 State 


Entity 


ARM: Renter Detail 


Column Name 


RKSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.42 State 


Entity 


ARM: Repair Detail 


Column Name 


RUSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.43 Status Description 


Entity 


ARM: ARMS/400 Cross Reference Status Table File 


Column Name 


XUSTDS 


Label Name 


Status Description 


System Name 




Data Type 


CHAR(6) 


Attribute Definition 




4.1.44 Telephone Number 


Entity 


ARM: Rental Location Master 


Column Name 


LOPHNO 


Label Name 


Telephone Number 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4. 1.45 Telephone Number 


Entity 


ARM: Repair Detail 


Column Name 


RUPHNO 


Label Name 


Telephone Number 


System Name 







Data Type 


NUMERIC(IO) 


Attribute Definition 




4.1.46 Vehicle Class 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZVHCS 


Label Name 


Vehicle Class 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.47 Vehicle Rate 


Entity 


ARM: Authorization(Claim Info) 


Colunui Name 


AZVHRT 


Label Name 


Vehicle Rate 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 




4.148 Zip Code 


Entity 


ARM: Rental Location Master 


Column Name 


LOZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 




4.1.49 Zip Code 


Entity 


ARM: Renter Detail 


Column Name 


RKZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 




4.1.50 Zip Code 


Entity 


ARM: Repair Detail 


Column Name 


RUZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 







5. Questions and Answers 



Issue Number: 368 



Question: Can the Adjuster shorten the number of days authorized without 
terminating the rental. 



Status: Closed - Resolved 



Resolution: 5-3-00, Brian Weingart, Kim DeVallance - No. After an ticket is 
open and has been authorized, the only modification allowed to the number of 
days authorized comes in the form of a termination. For example, if an adjuster 
sent us ten days and on the fifth day, decided to only give us a total of six (thereby 
removing the authorization for four days) the adjuster would have to terminate 
that rental as of the sixth day. 



Issue Number: 386 



Question: Should the Date of Loss be editable in Change Authorization or does it 
depend on the state of the reservation/ticket. 



Status: Closed - Resolved 



Resolution: 6-23-00, Brian Weingart, - Since Date of Loss is considered 
Insurance company information, the adjuster owns this information. The Adjuster 
can change this in either an reservation or open ticket status. This is editable until 
the rental is considered closed. 




